不可变数据结构设计应分层使用浅拷贝与深拷贝：顶层用浅拷贝保性能，嵌套变更处精准深拷贝，核心是“最小必要复制”；推荐immer或structuredClone等现代方案实现路径优化与类型支持。
在不可变数据结构设计中，浅拷贝与深拷贝不是非此即彼的选择，而是要按需分层使用——顶层用浅拷贝保证速度，嵌套变更处用精准深拷贝避免冗余，核心是“最小必要复制”。
明确哪些层级必须深拷贝
不可变更新只在实际被修改的路径上生成新节点，其余部分复用原引用。比如用 immer 的 produce 或 immutable-js 的 setIn，它们内部自动识别变更路径：只对被写入的嵌套对象做深拷贝，父级和未触碰的兄弟节点全部共享。
- 单层对象或数组（无嵌套）→ 直接用展开运算符或
Object.assign即可，属于安全浅拷贝 - 多层嵌套且仅局部修改（如
user.profile.address.city）→ 不要全量深拷贝整个user，而应沿路径创建最少新对象 - 需要保留函数、Date、Map 等特殊类型 →
structuredClone可靠但不支持 function；此时应手动处理或改用immer（它绕过序列化，直接操作代理）
避开 JSON.parse(JSON.stringify()) 的隐形开销
这个组合看似简单，实则在不可变场景中代价很高：每次调用都会完整遍历+序列化+反序列化，丢失类型、跳过 undefined、破坏循环引用，还无法保留方法。它不适合高频更新的不可变状态流。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 纯数据配置合并、一次性导出 → 可接受，但需校验是否含 Date/RegExp/undefined
- React state 更新、Redux action payload 处理 → 应禁用，改用
immer或structuredClone（若环境支持且不含 function） - 大数据量列表映射（如渲染前预处理）→ 手写轻量递归 + 类型判断比 JSON 方案快 2–5 倍，尤其当多数字段不变时
利用现代 API 减少手写逻辑
structuredClone 是目前最接近“开箱即用”的深拷贝方案，支持 Map、Set、Date、ArrayBuffer 和循环引用，性能优于 JSON 方案，在 Chrome 98+/Firefox 94+/Safari 15.4+ 及 Node.js 18.12+ 默认可用。
立即学习“Java免费学习笔记（深入）”；
- 适用场景：服务端状态快照、跨 Worker 传递、临时克隆纯数据结构
- 注意限制：遇到
function、undefined、Symbol会抛DataCloneError，需提前过滤或降级处理 - 不替代不可变库：它不做路径优化，仍是全量深拷贝；适合“复制后彻底隔离”，而非“局部更新”
用结构共享降低深拷贝频率
真正高效的不可变设计不靠减少深拷贝次数，而是让深拷贝结果能被复用。Immutable.js 和 immer 都基于持久化数据结构，同一棵树的不同版本之间共享未修改子树。
- 例如连续两次修改
list.push(x).push(y)，内部只新建两个尾节点，前面所有节点复用 - 对比手写递归深拷贝：每次都要从根开始复制，无法复用中间状态
- 代价是内存稍高（保留旧版本），但换来时间稳定性和可预测性，特别适合状态回溯、撤销重做等场景
