鸿蒙的@computed是基于依赖追踪的响应式计算装饰器，核心作用是自动关联依赖数据、实时计算结果，并在依赖变化时触发UI更新。

🔍 核心原理：三步实现响应式计算

@computed的工作流程可拆解为“依赖收集-结果缓存-自动更新”三个关键步骤，确保计算逻辑高效且响应式。

1. 依赖收集：记录计算用到的数据
   首次执行@computed修饰的函数时，鸿蒙框架会“监听”函数内部访问的所有响应式数据（如@State、@Prop、@Link修饰的变量），并将这些数据与当前computed属性建立关联，形成“依赖列表”。

2. 结果缓存：避免重复计算
   函数首次执行后，计算结果会被缓存。只要依赖列表中的数据没有发生变化，后续访问该computed属性时，框架会直接返回缓存结果，不重复执行计算逻辑，减少性能消耗。

3. 自动更新：依赖变化触发重新计算
   当依赖列表中的任意一个响应式数据发生修改时，框架会立即检测到变化，并触发computed函数重新执行，生成新的结果并更新缓存。同时，若该computed属性绑定了UI，框架会同步更新对应的UI视图。

📌 关键特性：为什么用@computed？

@computed的设计是为了解决“复杂数据计算与UI同步”的问题，核心特性直接服务于开发效率和性能：

• 响应式联动：无需手动监听数据变化，依赖数据改了，计算结果和UI会自动跟着改。
• 惰性计算：只有当依赖变化或首次访问时才计算，未被使用或依赖未变时不消耗资源。
• 简化逻辑：将复杂的“数据计算逻辑”从UI渲染代码中抽离，让代码更清晰（比如“计算购物车总价”“判断按钮是否可点击”等场景）。

⚠️ 注意事项：避免踩坑

使用@computed时，有两个关键限制需要遵守，否则会导致响应式失效或逻辑错误：

1. 禁止修改依赖数据
   computed函数只能是“纯计算逻辑”，不能在函数内部修改任何响应式数据（如给@State变量赋值），否则会导致依赖循环，引发框架报错。

2. 依赖必须是响应式数据
   函数内部访问的数据，必须是鸿蒙官方的响应式装饰器（@State/@Prop/@Link/@Provide等）修饰的变量。若访问普通变量（无响应式装饰），框架无法收集依赖，后续该变量变化时，computed不会重新计算。