ArkTS 状态管理的边界：什么该放进 @State，什么不该

ArkTS 的状态装饰器用起来很顺手，但顺手也容易滥用。最近重构一个列表页时，把几个体会整理下来。

第一，能由其他状态推导出来的值不要单独存。例如列表的选中数量，如果既存 count 又存 selectedIds，两者迟早会不同步。用 getter 或计算属性，单向数据流会干净很多。

第二，深层嵌套对象整体更新会触发大范围重渲染。把可变部分拆成独立子状态，或者用 @Observed 加 @ObjectLink 做局部观察，长列表滚动的帧率差异非常直观。

第三，@Prop 是单向拷贝，子组件改了不会回流父组件。需要双向同步时用 @Link，但要注意父子都持有同一份状态后，谁负责最终写回必须明确规定，否则会出现两个入口改同一个值的问题。

第四，不要把网络请求对象塞进状态里。请求的取消与重试属于逻辑层，混进 UI 状态后，页面重建时很容易出现重复请求。

第五，状态粒度尽量贴近渲染粒度。一个页面级的大对象动一下，整个页面 diff 都在跑；拆成几个小块之后，同样的交互能明显减少刷新范围。

小结：状态管理的目标不是把所有数据都变成响应式，而是让变化的影响面刚好等于需要更新的那一块 UI。