MobX中state、computed与action的区别及computed必要性问询

先明确三个核心概念的本质：

• State（状态）：应用的原始数据源，是需要追踪变化的基础数据。比如你的示例里store.count，它是直接存储的数值，所有衍生数据的源头。State的变化会触发依赖它的响应式更新。
• Computed（计算属性）：基于State（或其他Computed）衍生的缓存式派生值，本质是纯函数。比如store.Double，它依赖count，只有当count变化时才重新计算，多次访问且count未变时直接返回缓存结果。
• Action（动作）：修改State的唯一合规入口（严格模式下强制要求），封装状态修改逻辑。比如doubleThis()，负责直接修改count的值，是触发State变化的手段。

State vs Computed：核心差异 #

1. 本质与数据源
   • State是原始数据容器，存储的是可被修改的直接值，是被动的，需要通过Action触发变化。
   • Computed是衍生计算结果，不能独立存在，必须依赖State/其他Computed，自身无法直接修改，只能随依赖项变化自动更新。
2. 缓存机制
   • State无缓存，每次访问都是直接读取当前存储值。
   • Computed自带智能缓存：仅当依赖的状态发生变化时才重新计算，否则复用缓存结果，避免重复执行计算逻辑。
3. 可写性
   • State可写（必须通过Action修改）。
   • Computed默认只读（getter），即使设置setter，本质也是通过修改依赖的State间接更新自身，而非直接修改Computed的值。

能不能用Action替代Computed？ #

绝对不行，二者职责完全不同，强行混用会引发问题：

• 性能浪费：如果用Action模拟Computed（比如写一个getDouble()方法返回count*2），每次调用都会重新计算，哪怕count没有变化。而Computed的缓存能避免这种无意义的重复计算，尤其当计算逻辑复杂时（如大数组过滤排序），性能差异会非常明显。
• 职责混乱：Action的核心是修改State，Computed的核心是计算衍生值。把计算逻辑塞进Action，会混淆“修改状态”和“计算结果”的边界，代码变得难以维护。
• 失去响应式优势：MobX的自动依赖追踪和更新是基于State和Computed的，Action只是修改State的工具。用Action替代Computed，无法利用MobX的自动更新机制，需要手动处理状态变化后的同步逻辑，违背了MobX的设计初衷。

为什么必须用Computed？ #

1. 性能优化：缓存机制避免重复计算，大幅降低不必要的性能开销。
2. 代码复用：将重复的计算逻辑封装成Computed，多个组件或模块可以直接复用，不用重复编写相同代码。
3. 自动响应式更新：依赖的State变化时，Computed自动更新，所有依赖它的组件或响应逻辑会同步触发更新，无需手动维护状态同步。
4. 代码结构清晰：明确区分“原始状态”和“衍生状态”，符合单一职责原则，代码可读性和可维护性更高。

举个反例对比：
如果不用Computed，改用方法实现：

class CountNumber {
  @observable count = 0;
  @action doubleThis() {
    this.count *= 2;
  }
  getDouble() {
    console.log("执行计算");
    return this.count * 2;
  }
}

连续调用三次store.getDouble()，控制台会打印三次“执行计算”；而用@computed get Double()，只有当count变化时才会打印一次，之后访问都是取缓存。

内容的提问来源于stack exchange，提问作者CODEforDREAM