Lodash 深拷贝和深比较怎么用？cloneDeep 与 isEqual 有哪些坑？

Lodash 的 cloneDeep 和 isEqual 经常出现在状态管理、表单快照、配置对比和缓存判断里。它们解决的是两个相近但不同的问题：深拷贝是生成一份互不影响的新数据，深比较是判断两份嵌套数据内容是否一致。真正要注意的不是 API 怎么写，而是别把它们当成“任何对象都安全、任何场景都划算”的万能按钮。

clone、cloneDeep 和 cloneDeepWith 怎么选？

_.clone 是浅拷贝，只复制第一层引用。数组里的对象、对象里的数组还是同一份，改嵌套字段会互相影响。_.cloneDeep 会递归复制嵌套结构，适合表单初始值、可编辑草稿、配置模板这类需要隔离修改的场景。

javascript
import _ from 'lodash';

const source = {
  user: { name: 'Ada' },
  roles: ['admin']
};

const draft = _.cloneDeep(source);
draft.user.name = 'Grace';

console.log(source.user.name); // Ada

_.cloneDeepWith 用在默认拷贝不符合业务预期时，比如 DOM 节点、类实例、特殊对象。它允许你对某些值自定义复制方式，返回 undefined 则继续走 Lodash 默认逻辑。边界是自定义函数越复杂，越容易制造半深半浅的怪对象，最好只处理明确类型，不要在里面写一堆业务分支。

isEqual 和 isEqualWith 解决什么问题？

_.isEqual 比较的是值结构，不是引用地址。两个对象不是同一个引用，只要字段和值一致，结果也可以是 true。它适合判断表单是否改动、配置是否变化、缓存参数是否相同。

javascript
const initial = { name: 'Ada', skills: ['js', 'node'] };
const current = { name: 'Ada', skills: ['js', 'node'] };

console.log(initial === current); // false
console.log(_.isEqual(initial, current)); // true

_.isEqualWith 适合业务上“看起来不一样，但应该算相等”的情况。比如金额字符串 '10.00' 和数字 10，或者大小写不敏感的标签比较。取舍上，这种宽松比较要非常克制，因为它会改变团队对“相等”的直觉；如果规则只在一个页面成立，就不要封成全局通用方法。

什么时候不要做深拷贝？

如果只是更新对象里一两个字段，整棵树 cloneDeep 往往太重。更好的写法是复制沿途分支，让未变化的部分继续共享引用，这也是很多状态管理方案强调不可变更新的原因。另一个不适合深拷贝的场景是缓存对象或服务实例，它们背后可能连着连接、订阅、定时器或私有状态。深拷贝能解决“误改原对象”的问题，但不能替代清晰的数据所有权设计。

追问

cloneDeep 能不能替代 JSON.parse(JSON.stringify())？

很多场景可以替代，而且更稳，因为 JSON 方案会丢掉 Date、Map、Set、undefined、函数和循环引用等信息。cloneDeep 对常见对象类型处理更完整，也能避免循环引用直接报错的问题。取舍是 JSON 方案简单、可预测、输出一定是纯 JSON 数据；如果你就是要把数据变成可传输对象，它反而更符合目标。踩坑是不要把“深拷贝”误认为“序列化”，这两个需求边界不同。

cloneDeep 会不会有性能问题？

会，尤其是对象很大、嵌套很深、或者在渲染过程中频繁执行时。它需要遍历整棵数据结构，数据越复杂成本越高，在 React render 或 computed getter 里随手 cloneDeep 很容易造成卡顿。更好的做法是只拷贝要修改的分支，或者用不可变更新工具减少整体复制。性能排查时先看调用频率，再看数据大小，不要一上来就怪 Lodash。

isEqual 可以用来判断 React 组件是否需要更新吗？

可以，但要谨慎。深比较本身有成本，如果每次渲染都拿大对象做 isEqual，可能比直接重新渲染还贵。适合的场景是对象不大、变化不频繁、重新计算或重新渲染成本更高。边界上，函数、类实例、不可枚举属性等比较结果未必符合你的业务预期，组件性能优化不要只靠一个深比较函数。

isMatch 和 isEqual 有什么区别？

isEqual 要求两边整体结构和值都一致，isMatch 只要求目标对象包含 source 指定的那部分字段。做筛选条件、权限匹配、局部断言时，isMatch 更方便；做快照比较、变更判断时，用 isEqual 更准确。踩坑是 isMatch 的“部分匹配”容易让人误以为对象完全相同。涉及安全权限时，不要只靠局部匹配判断完整授权状态。

深拷贝特殊对象时有哪些边界？

cloneDeep 能处理很多常见结构，但业务对象不一定只由普通对象和数组组成。DOM 节点、文件对象、流、数据库连接、带私有状态的类实例，都可能需要自定义处理或根本不该复制。边界原则是：数据对象可以拷贝，资源句柄不要随便拷贝。遇到这类对象，优先设计清楚生命周期，而不是用深拷贝把引用问题压下去。