学习笔记：ArkTS 状态管理从“能跑”到“好维护”

最近在写一个鸿蒙小页面时，我终于把状态管理这件事想明白了一点：页面能跑起来只是第一步，状态放得对不对，才决定后面改起来累不累。以前我习惯把所有变量都堆在页面里，写的时候很顺，可一旦要加一个筛选条件或者多一个子组件，改动就到处牵连。

先说最常用的 @State。它属于当前组件自己，适合只在当前页面内部使用的状态，比如输入框的文字、列表是否展开。把它理解成组件的“私有数据”就好，不要让它背上跨组件共享的任务，否则很快就会失控。

如果子组件只是展示父组件传下来的值，用 @Prop 就够了。父组件变，子组件跟着变，数据是单向流动的，排查问题时顺着这条线找，一般不会迷路。需要子组件改回父组件的数据时，再考虑 @Link，它是双向同步的，但正因为双向，滥用会让数据流变得难追踪，我现在只在确实需要回写的场景才用它。

对象和数组要格外小心。@Observed 修饰的类配合 @ObjectLink，可以让嵌套属性的变化被界面感知到；直接修改普通对象的属性，界面可能纹丝不动。我踩过这个坑：数据明明变了，页面却没刷新，后来把模型改成 @Observed，问题才消失。还有一点，数组不要只改某一项就指望刷新，替换成新数组往往更可靠。

最后是我现在养成的习惯：动手写界面之前，先画一张很小的状态归属图，写清楚每个状态属于谁、谁能改、谁只需要读。状态放得越低、归属越清晰，组件复用起来越轻松；反过来，把所有状态都提升到顶层，看似统一，其实会让顶层组件越来越臃肿。状态管理没有银弹，关键是让每一次变化都有明确的来源和去向。