闭包通过作用域隔离实现变量真正不可变：内部变量无法被外部访问或修改，仅暴露经校验的变更方法。如订单状态机中，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 上的可配置属性，那“不可变”就只是幻觉。
