区分数据生命周期再选型。页面内临时数据用@State，组件树内共享用@Provide@Consume，全局共享用AppStorage，要持久化再加。别所有数据都往 AppStorage 里塞。的 key 要统一管理。持久化 key 散落各处容易冲突，建议集中定义常量。同步引用时注意 type。的类型要和声明一致，类型对不上会有隐式转换问题。持久化数据只存可序列化的。存的是可序列化数据，函数、回调、

子组件改的是自己那份，父组件不知道。适合"父组件的数据子组件只读展示，子组件可以基于它做本地调整"的场景。短期可以用方式 2 快速解决，长期和团队规范应该用方式 1，否则代码里到处是别扭的整体替换。是组件自己的状态，只有声明它的组件能读取和修改。它是所有状态管理的起点。嵌套对象改属性不刷新是状态管理里最隐蔽的问题之一。反过来讲，如果子组件需要改父组件的数据，却用了。，那是个 bug——子组件改了父

写界面时最头疼的是"数据变了界面怎么跟着变"。ArkUI 的状态管理就是解决这个问题：你声明数据是"状态"，框架在数据变化时自动刷新用到它的组件。所以性能上，状态管理不是"整个页面重渲染"，而是"最小范围刷新"。这个分层让"全局共享"和"局部 UI 状态"各司其职，不会把所有数据都塞进全局导致混乱。理解"所有权"这个概念，选装饰器就不容易错。下一篇展开讲组件内状态和父子传递的细节。的读写有开销，只

组件"长什么样"是组件属性的事，组件"放在哪"是布局的事。ArkUI 提供了多种布局容器，每种解决一类排列问题。选对布局，界面适配就顺；选错布局，写一堆 margin 硬调位置，换个屏幕就乱。

资讯流、商品列表、聊天记录、通讯录，几乎每个应用都有列表。ArkUI 里列表用ListListItem构建，网格用GridGridItem，但真正决定性能的是懒加载机制。

ArkUI 的系统组件就是界面里的"零件"——文本框、图片、按钮、输入框、单选框、进度条这些。把它们组合起来，就拼出一个完整页面。这系列先讲最常用的几类：文本、图片、按钮、输入框，以及承载它们的通用属性。

但你如果打算做长期维护的应用，还是尽早转声明式——数据驱动 UI 的写法在状态多了之后明显更省心，不用在 JS 里手动管理一堆 DOM 更新。Engine 层负责构建 DOM 树和布局计算，这正是声明式范式省掉的部分，也是类 Web 范式性能略逊的原因。是双向感知的（数据驱动 UI，事件回调写回数据），类 Web 范式里这个"写回"要自己在事件里做，这就是单向和双向在开发体验上的差别。类 Web

但你如果打算做长期维护的应用，还是尽早转声明式——数据驱动 UI 的写法在状态多了之后明显更省心，不用在 JS 里手动管理一堆 DOM 更新。Engine 层负责构建 DOM 树和布局计算，这正是声明式范式省掉的部分，也是类 Web 范式性能略逊的原因。是双向感知的（数据驱动 UI，事件回调写回数据），类 Web 范式里这个"写回"要自己在事件里做，这就是单向和双向在开发体验上的差别。类 Web

命令式编程里，你要告诉程序"怎么做"——先创建按钮，再设置它的位置，再绑定点击回调。每一步都是具体的操作指令。声明式编程里，你只告诉程序"要什么"——这里有个按钮，文字是"登录"，点它触发这个动作。至于按钮怎么绘制、怎么布局、怎么响应，统统交给框架。关键区别：声明式里count++之后你没有碰任何 UI 代码，但界面会自动更新。这就是"数据驱动 UI"，开发者只写引起界面变化的数据，界面怎么变交给

先判断分词器支持，不支持要降级中文用 ICU 分词器是中文检索的关键FTS 表是虚拟表：用创建用 MATCH 查询：比 LIKE 快几个数量级双表结构：普通表存完整数据，FTS 表存检索字段，JOIN 关联参数化绑定：MATCH 查询也要用?占位防注入。