Object.freeze() 仅浅冻结对象顶层属性，嵌套对象仍可修改；需递归冻结或使用 immer 等库实现深度不可变；其核心价值在于保障状态一致性、调试可追溯性与并发安全，而非性能优化。
Object.freeze() 是 JavaScript 中让对象“定格”在当前状态的最直接手段：它把对象顶层属性全部设为不可写、不可配置、不可枚举，且禁止增删属性。但它**不是深度冻结**——嵌套对象照旧可改，这点必须清醒。
为什么 Object.freeze() 常被误用？
很多人以为调用一次就万事大吉，结果发现：user.address.city = "Shanghai" 依然成功，而 user.name = "Alice" 却静默失效。这是因为 Object.freeze() 只冻结第一层，对 user.address 这个子对象本身不做任何处理。
- 冻结后，在非严格模式下修改顶层属性会静默失败；严格模式下则抛出
TypeError -
Object.isFrozen(obj)可以可靠检测是否已冻结（注意：它不检查嵌套） - 它不改变原型链，也不影响 getter/setter 的行为（只要它们没被显式禁用）
- 数组也被视为对象，
Object.freeze([1,2,3])后不能 push/pop，但若元素是对象，如arr[0].id = 999仍合法
真正需要“完全不可变”时，怎么递归冻结？
手动递归是最常见也最可控的方式，尤其适合配置对象、常量枚举等生命周期内绝不变更的数据：
function deepFreeze(obj) {
if (obj && typeof obj === 'object' && !Object.isFrozen(obj)) {
Object.getOwnPropertyNames(obj).forEach(prop => {
if (obj[prop] !== null && typeof obj[prop] === 'object') {
deepFreeze(obj[prop]);
}
});
Object.freeze(obj);
}
return obj;
}
- 务必先检查
!Object.isFrozen(obj)，避免重复冻结引发无限循环（尤其有循环引用时） - 该函数不处理
Map/Set/Date/RegExp等内置类型，仅覆盖 plain object 和 array - 生产环境若需强保证，建议用
immer或immutable-js，而非手写递归——后者易漏边界（如__proto__、访问器属性）
不可变数据到底带来了什么实际好处？
不是为了“炫技”，而是解决真实痛点：
-
调试更省心：React/Vue 组件依赖浅比较（
===）判断是否重渲染。若 state 被意外修改，shouldComponentUpdate或React.memo就会失效，导致界面卡顿或视图不同步 - 状态可追溯：Redux DevTools 的“时间旅行”调试，本质就是靠每次 dispatch 都返回新对象，历史快照才不会互相污染
- 并发更安全：Web Worker 间传递对象时，若主进程和 worker 共享引用并随意修改，极易出现竞态。不可变数据天然规避此问题
- 逻辑更可测：纯函数 + 不可变输入 = 输出只取决于输入。单元测试无需 mock 复杂状态，断言更稳定
别迷信性能优化，先守住正确性
有些资料说 Object.freeze() 能让 JS 引擎做优化，这没错，但现代 V8 对它的收益已非常有限，且高度依赖具体使用模式。你很难测出真实提升，却很容易因误信“冻结=提速”而忽略真正瓶颈。
立即学习“Java免费学习笔记（深入）”；
- 冻结一个 10KB 的配置对象，启动耗时差异几乎为 0；但若在 render 循环里反复调用
deepFreeze，反而拖慢首屏 - 不要对 props/state 自动冻结——React 已通过
Object.is和不可变更新约定保障一致性，额外冻结徒增心智负担 - 真正该冻结的，只有那些你明确声明“永远不该变”的东西：比如
CONSTANTS、HTTP_METHODS、STATUS_CODES
Object.freeze() 能兜底所有层级；而不可变性的价值，从来不在语法糖或性能数字上，而在你改一行代码时，心里清楚——它不会悄悄掀翻其他模块的桌子。 
