前端 JavaScript 不可变数据与结构共享

不可变更新表示不直接修改已有数据，而是生成新的状态结果。它让变化更容易追踪，也适合依赖引用比较的界面框架和状态管理工具。不可变不等于每次深拷贝整个数据树，关键是只复制发生变化的路径。

一、直接修改会隐藏变化

若状态对象原地改变，订阅方可能无法通过引用变化发现更新，历史状态也会被覆盖。多个组件共享同一对象时，副作用更难定位。

const nextUser = {
    ...user,
    profile: {
        ...user.profile,
        displayName: "新名称",
    },
};

示例只复制被修改路径上的对象，其他未变化分支仍可共享。

二、复制范围要准确

对象展开只做浅复制。若先复制外层再修改嵌套对象，原状态仍会被改动。

const nextState = { ...state };
nextState.preferences.theme = "dark";

上例会修改原来的 preferences 引用。正确做法是继续复制每层被修改的对象，或使用经过理解和约束的不可变更新工具。

三、数组操作要返回新数组

添加、删除和更新数组项时，使用 map、filter、slice 等返回新数组的方法。排序和原地反转会修改原数组，若输入来自状态，应先复制再操作。

const nextItems = items.map((item) =>
    item.id === changedId ? { ...item, selected: true } : item
);

保持未变化项的引用，有助于列表项级别的浅比较，也减少不必要渲染。

四、结构共享与性能

深拷贝会复制整棵树，成本随数据规模增长，还可能丢失特殊对象语义。结构共享只创建变化路径上的新对象，兼顾不可变语义和内存效率。

不可变操作本身也有成本。对于短小局部状态，不必引入复杂工具；对于嵌套更新频繁的领域模型，可以用 reducer 或专门工具集中管理更新规则。

五、把更新写成纯转换

reducer 接收旧状态和动作并返回新状态，不应直接操作 DOM、发请求或修改外部变量。副作用放在明确的协调层，状态转换就容易单独推理和验证。

六、避免误用冻结

Object.freeze 只冻结对象自身属性，不会递归冻结嵌套对象。开发期的深度冻结可以帮助发现原地修改，但不应把冻结当成不可变更新的替代方案。

更新路径的实践建议

• 更新嵌套状态前先画出被修改字段到根对象的路径，只复制这些节点，并保留其他分支引用，避免全树深拷贝。
• 多个组件持有同一对象时，更新入口应归属明确的状态所有者。禁止子组件暗中改写对象，能减少跨区域的隐式联动。
• 排序和反转等会原地修改数组的方法要先判断数据来源。若来自共享状态，先复制或使用不会改写输入的实现。
• 结构共享让浅比较有效，但只有更新时遵守不可变约定才成立。偶尔一次原地修改就会造成界面不刷新或历史状态被污染。
• 复杂更新规则可以集中放入 reducer 或领域函数，并用状态前后值验证行为；不要让多个页面分别实现同一条更新规则。

复核场景

编辑一条嵌套记录时，只创建根对象、记录对象和被修改字段所在分支的新引用，其他记录保持原引用。这样选择器能快速识别目标变化，列表中未修改的行也能跳过更新。若状态变化后界面没刷新，优先排查是否原地改写了某一层对象。

场景取舍补充

不可变更新提高了状态变更的可见性，但不意味着所有数据都必须复制。对临时局部变量可直接修改；进入共享状态、需要历史比较或依赖引用订阅时，再采用不可变更新约定。

调试状态历史时，比较新旧引用可以快速判断变化路径；若整棵树每次都更换引用，检查是否存在不必要的深复制。

团队应统一共享状态的更新约定，并在开发环境发现意外原地修改。明确规则比混用可变和不可变写法后再靠每个页面猜测引用变化更可靠。

七、嵌套状态的路径更新

更新嵌套对象需要沿修改路径复制每一层。只复制根对象仍可能修改旧状态中的嵌套引用；复制整棵树又会让所有对象引用变化，触发无关消费者更新。

const nextState = {
    ...state,
    profile: {
        ...state.profile,
        preferences: {
            ...state.profile.preferences,
            theme: "dark",
        },
    },
};

更新逻辑变深时，可用 reducer、明确的领域函数或成熟的不可变更新工具降低手写错误，但要理解其代理和草稿语义。

八、数组、Map 与 Set 的更新

数组原地排序、反转和 splice 会修改原数据。Map 和 Set 的 set、add、delete 同样是原地变更；若它们作为状态，需要创建新容器后更新。只在外层复制对象而复用已修改的 Map，引用比较仍看不出变化。

结构共享适合列表更新：变化项创建新对象，不变项保留引用。稳定键配合浅比较可以让列表只更新受影响行。

九、不可变与性能

不可变操作有分配成本，但深复制通常更昂贵。使用性能工具确认瓶颈后再考虑结构共享、分块状态或专门数据结构。不要为省一次对象创建而引入难以追踪的全局可变状态。

开发期冻结可以捕获误修改，但浅冻结不会冻结嵌套对象。深度冻结大状态会增加成本，适合测试或调试而非不加区分地用于所有生产路径。

十、历史记录和调试

不可变状态可保留先前版本，支持撤销和时间旅行，但历史快照也会占内存。只保留必要数量，或保存动作并从检查点重建。高频大对象不应无限堆积完整历史。

实施中的取舍与复核

不可变更新的目标是让状态变化可追踪，而不是让所有数据都深拷贝。只复制从根到变化叶子的对象路径，未变化分支保持共享，能降低分配成本并帮助浅比较判断更新范围。若每次只改一个字段却复制整棵大型数据树，可能把性能问题从渲染转移到分配与垃圾回收。

冻结对象可以在开发阶段发现意外修改，但深冻结成本较高，也不应成为生产环境无差别的运行开销。外部接口返回的数据先转换为应用需要的领域结构，避免多个页面直接持有同一个可变对象并互相影响。组件内部可以保留局部可变草稿，再在提交时生成不可变结果，但要明确草稿与已保存状态之间的同步规则。

共享引用会影响缓存和选择器。若修改了已有对象而引用没有变化，浅比较可能错过更新；若每次都创建新对象，又可能导致下游订阅者全部重算。把数据规范化并按实体标识更新，只通知依赖变化部分；派生数组可由选择器按输入引用缓存，并明确缓存何时失效。

测试可验证原对象和未修改分支保持不变，同时新状态包含预期变化。涉及数组排序、删除和嵌套字段时，确认不会原地操作共享数据。性能测试应使用接近真实规模的数据，比较复制策略、计算耗时和分配；只有测量表明结构共享或专门数据结构有收益时，再引入额外复杂度。

复核案例与后续维护

状态快照常用于撤销、重放和协作同步，但快照大小与保留数量应设限。大型文档每次都完整复制会带来明显内存增长，可以按编辑操作记录增量并定期压缩。撤销栈需要决定合并连续输入的时机，并在成功保存或切换实体时处理历史记录。

不可变结构对调试和并发更新有帮助，但对象引用稳定不代表业务值永远有效。远端刷新可能返回新版本，需要明确本地草稿与服务端版本如何合并。状态变更记录可标记来源和版本，发现冲突后展示差异，避免简单用新对象替换导致编辑丢失。

测试应在一系列增量操作后验证撤销重做、共享分支和序列化恢复。对结构共享优化做性能测量，观察小改动是否减少更新范围，同时监测分配和快照内存。选择不可变方案的目的应是可预测性与协作，而不是仅仅追随编码风格。

总结

不可变更新通过新引用表达变化，结构共享只复制被修改路径。注意浅拷贝边界，使用返回新数组的方法，并将纯状态转换与副作用分开，可以让状态历史、渲染比较和调试都更清楚。