JavaScript 里的“冻结”没那么简单：Object.freeze 避坑指南

接手新项目时，经常发现这样的代码：为了表示某个配置项不可变，开发者习惯性地给对象加了个 const，甚至顺手调用了 Object.freeze()。心想这下万无一失了吧？结果运行时，后台还是报错了——某些嵌套属性竟然被修改了。这种“以为冻结却未冻结”的尴尬，相信不少前端工程师都遇到过。

这锅得 Object.freeze 背一半，另一半其实是我们对“冻结”程度的误解。在 JavaScript 引擎眼里，冻结只发生在直接属性上。也就是说，它像是一把锁，只能锁住最外层的抽屉。如果抽屉里还放着另一个盒子（嵌套对象），那个盒子里的东西依然可以随意摆放。

来看个典型的翻车现场：

const config = {
  api: {
    url: 'https://api.example.com',
    timeout: 5000
  }
};

Object.freeze(config);

// 以下这行代码居然没有报错！
config.api.timeout = 1000; 

很多人第一反应是引擎出 bug 了。其实并不是，config 对象本身确实是不可写的，但 config.api 指向的是一个引用地址。只要拿到这个引用，就能继续修改里面的内容。这就好比锁住了保险箱的大门，却没锁里面的抽屉。

如果你真的需要彻底封锁整个数据树，就得手动实现深冻结。核心思路很简单：递归遍历。遇到值是对象的，就再次调用冻结函数。

function deepFreeze(obj) {
  // 取出所有键名
  const propNames = Reflect.ownKeys(obj);

  // 对每个值进行递归冻结
  for (const name of propNames) {
    const value = obj[name];
    if (value && typeof value === 'object') {
      deepFreeze(value);
    }
  }
  // 最后冻结当前对象
  return Object.freeze(obj);
}

这段逻辑虽然解决了问题，但要注意性能开销。在处理大型响应式数据或复杂 Redux Store 时，深冻结可能会拖慢初始化速度。所以在实际开发中，通常建议仅在数据模型确定的底层配置上使用深冻结，而对于频繁变更的业务状态，保持灵活性可能比绝对安全更重要。

在现代前端框架生态里，比如 Vue 3 或 React，我们其实很少直接在业务逻辑里手动调用 Object.freeze。Vue 的 readonly 或 React 的不可变数据更新模式，本质上是在更合适的抽象层级上解决了同样的问题。手动冻结更适合那些纯工具类库，或者对外暴露的配置接口，用来防止外部污染内部状态。

此外，还有一个容易忽视的细节：冻结后的对象依然是可枚举的。这意味着你可以遍历它的属性，只是不能增删改。如果你期望冻结意味着“完全隐藏”，那可能会失望。这在调试阶段有时候反而是好事，因为你能看到所有字段，却碰不到它们，相当于一个只读视图。

写到这里，不妨反思一下：为什么我们会执着于冻结对象？很多时候是为了防御性编程，减少副作用。但在团队协作中，依靠语言特性的强制约束，往往不如约定优于配置来得高效。Object.freeze 是一个很好的辅助工具，特别是在构建不可变基础设施时，但它不是银弹。

真正健壮的系统，靠的是清晰的契约和合理的数据流设计，而不是单纯依赖几个 API 来保证安全。下次再想给数据加锁前，先问问自己：这块数据真的需要全链路保护吗？还是说，只需要在最关键的边界处设一道防线就够了？恰到好处的限制，才是好代码应有的姿态。