JavaScript无原生不可变类型，需通过约定或工具实现；推荐Immer（语法可变、产出不可变）、次选Immutable.js（功能强但渐进淘汰），简单场景可用Object.freeze或展开运算符。
JavaScript 本身没有原生的不可变数据类型，但可以通过约定、工具方法或专门库来模拟和保障不可变性。核心思路是：不直接修改原始对象或数组，而是每次“变更”都返回一个新副本。
手动实现不可变操作（基础但易出错）
用 Object.freeze、Object.assign、展开运算符（...）、map/filter/concat 等纯函数式方法可以避免直接修改。
-
Object.freeze(obj)只冻结第一层，嵌套对象仍可变，适合简单常量场景 - 更新对象属性推荐：
{ ...original, key: newValue } - 更新数组元素推荐：
[...arr.slice(0, i), newValue, ...arr.slice(i + 1)]或用map - 深层更新需递归克隆，手写容易遗漏或性能差，不建议复杂场景长期依赖
Immer：最主流的轻量级不可变方案
Immer 允许你用“看似可变”的语法编写逻辑，内部自动产出不可变新对象，学习成本低、调试友好、性能优化好。
- 基本用法：
produce(original, draft => { draft.x = 5; })—— 写起来像改原对象，实则返回新对象 - 支持嵌套对象、数组、Map/Set，也兼容 Redux Toolkit（底层即基于 Immer）
- 不侵入数据结构，输出仍是普通 JS 对象，无运行时依赖
- 注意：不要在
produce回调里解构赋值或提前 return 原始引用，会绕过代理机制
Immutable.js：功能完备但渐进淘汰的重型方案
由 Facebook 推出，提供 List、Map、Set、Record 等专属不可变集合类型，带丰富 API 和持久化结构优化。
立即学习“Java免费学习笔记（深入）”；
- 优势：O(log₃₂ n) 时间复杂度的高效更新、强类型支持（配合 TypeScript 更佳）、内置
is()深比较 - 缺点：数据必须转成它的类型（如
Immutable.Map()），与原生数组/对象不兼容，调试时显示为自定义类实例 - 现状：维护放缓，社区已普遍转向 Immer + 原生对象组合方案
其他轻量选择
如果只需要简单工具函数，可考虑：
-
immer已足够覆盖 90% 场景，无需额外引入 -
rfx或updeep提供声明式更新（如u({ a: { b: 2 } }, state)），适合配置驱动更新 -
lodash/fp的set、update等函数也支持不可变路径更新，但需注意它默认不深克隆原型链
基本上就这些。日常开发推荐从 Immer 入手，兼顾可读性、安全性和迁移成本。真正需要极致性能或历史项目兼容时，再评估 Immutable.js 或定制方案。
