极致性能复用需坚持“结构稳定、数据轻量、缓存可控”：结构上控制复用边界、慎用嵌套@Reusable、优先用@Builder、单层标记、统一reuseId区分形态；数据上杜绝函数入参、aboutToReuse仅赋值、props用基本类型或不可变对象、响应式改用@Observed/@ObjectLink；缓存上显式设语义化reuseId、高频项独立建池、跨父组件改用BuilderNode、cachedCount限容；验证须通过DevTools观测创建事件、日志统计复用/销毁次数，并确保失效时优雅降级。
要实现极致的性能复用，关键不是堆砌复用数量，而是让每次复用都真正避开节点重建、状态重置和渲染树重计算。核心在于“结构稳定、数据轻量、缓存可控”三个支点。
结构层面：控制复用边界，避免嵌套污染
组件嵌套越深，复用链路越脆弱。鸿蒙平台明确指出：在 @Reusable 组件中再嵌套另一个 @Reusable 子组件，会触发多层 aboutToReuse 回调，扩大刷新范围，反而拖慢性能。
- 优先用 @Builder 替代浅层自定义组件——Builder 是纯函数式构造，无实例生命周期，不进缓存池，但能复用内部逻辑和子节点
- 对必须封装的状态组件，坚持单层 @Reusable：只在最外层列表项（如 ListItem）上标记 @Reusable，其内部子组件（图标、文本等）保持普通声明
- 避免 if/else 动态切换布局结构；若需多形态，统一用 reuseId 区分缓存组，例如
reuseId='item-card'和reuseId='item-list'
数据层面：精准传递，杜绝副作用入参
复用时的数据更新必须轻量、可预测。鸿蒙四板斧特别强调：函数类型参数会强制触发组件构造，若该函数含异步或计算逻辑，将直接阻塞复用流程。
- aboutToReuse(params) 中只做字段赋值，不调接口、不执行复杂计算、不修改全局状态
- 所有 props 应为基本类型（string/number/boolean）或不可变对象（如通过 Object.freeze 或结构化克隆传入）
- 需要响应式联动的状态，改用 @Observed + @ObjectLink 等细粒度响应机制，而非整块对象传入
缓存层面：按需建池，显式管理复用域
系统默认以组件名作 reuseId，容易导致不同业务场景下的同名组件互相挤占缓存。真正的极致复用，要求开发者主动划分缓存空间。
- 对高频固定结构（如消息列表项），设置语义化 reuseId：
reuseId='msg-item-standard' - 对跨父组件需共享的子组件（如统一 Avatar），放弃 @Reusable，改用 BuilderNode 全局注册，绕过父级缓存池隔离限制
- 配合
cachedCount(8)显式控制缓存数量，避免内存堆积；滑动列表中建议设为可视区高度 × 2～3
验证与兜底：复用是否真生效？
复用不是加个装饰器就完事。必须验证缓存命中率：
- 打开 DevTools → Performance 面板，滑动列表，观察 “Component Create” 事件是否大幅减少
- 在 aboutToRecycle 中打日志，确认销毁前是否进入缓存；在 aboutToReuse 中计数，对比创建次数与复用次数
- 当复用失效（如布局突变、key 错误、reuseId 冲突），降级为普通组件渲染，避免白屏或错乱
