闭包通过作用域隔离实现变量真正不可变：内部变量无法被外部访问或修改，仅暴露经校验的变更方法。如订单状态机中，state和流转规则封装在闭包内，仅提供getState()和带校验的transition()，杜绝直接操作。

闭包怎么让变量真正“不可变”

JavaScript 里 const 只能防止绑定被重新赋值，不能阻止对象属性被修改。真正的不可变性得靠作用域隔离——闭包把状态锁在函数内部，外部连读都做不到，更别说改了。

关键不是“不改”，而是“没法改”。比如业务里一个订单状态机，初始状态、允许的流转路径、当前值，全藏在闭包里，只暴露几个经过校验的变更方法：

function createOrderStateMachine() {
  let state = 'draft'; // 外部永远拿不到这个引用
  const allowedTransitions = { draft: ['submitted'], submitted: ['confirmed', 'rejected'] };

  return {
    getState() { return state; },
    transition(to) {
      if (allowedTransitions[state]?.includes(to)) {
        state = to;
        return true;
      }
      throw new Error(`Invalid transition: ${state} → ${to}`);
    }
  };
}

调用 createOrderStateMachine() 返回的对象，getState 只能读快照，transition 是唯一入口，且带校验。没有 getter/setter 暴露原始变量，也没有 state 属性可枚举。

为什么不用 class 或模块级 const

Class 的实例属性默认是可写的，哪怕加 readonly（TypeScript）也只是编译期提示，运行时照样能 obj.state = 'hacked'；模块顶层的 const state = 'draft' 更危险——它只是个常量值，没法承载状态变迁逻辑。

闭包胜在三点：

• 每次调用 createOrderStateMachine() 都生成独立作用域，多个订单互不干扰
• 状态变量生命周期与返回对象绑定，垃圾回收可控
• 所有副作用（如日志、事件通知）可集中写在 transition 内，避免散落在各处

容易踩的坑：意外泄露引用

闭包防篡改的前提是——别把内部对象原样抛出去。下面这段代码就破功了：

return {
  getState() { return { state }; }, // ❌ 返回新对象还行，但若返回 { state } 就等于暴露了可变副本
  getData() { return internalData; } // ❌ internalData 是数组或对象？外部直接 push / assign 就改了内部状态
};

正确做法：

• 返回结构化克隆：JSON.parse(JSON.stringify(internalData))（仅限纯数据）
• 或返回只读代理：return Object.freeze({ ...internalData })
• 更稳妥的是只返回计算结果，而非原始数据结构，比如 getItemsCount() 而非 getItems()

和 Immutable.js 或 Immer 冲突吗

不冲突，但定位不同。Immutable.js 解决的是“值不可变”，闭包解决的是“状态不可见”。前者适合高频更新的嵌套数据（如 Redux state），后者适合有明确生命周期和规则约束的业务实体（如订单、支付单、审批流）。

混用时注意：别在闭包里存 Immutable 实例后又用 .set() 改它——那只是换了个不可变值，但闭包外仍可能通过其他引用拿到旧版本。真正要的是“只有一个权威入口”，所以 transition 方法里该用 Immutable.set() 就用，但必须确保所有读取都走 getState()，而不是缓存过期的快照。

最易被忽略的一点：闭包本身不提供深冻结，也不拦截原型链访问。如果业务对象上有方法返回了内部数组引用，或者用了 Object.prototype 上的可配置属性，那“不可变”就只是幻觉。