Object.assign 浅拷贝：别被“一键合并”骗了，真正该抠的细节都在这

日常切页面或维护老项目时，合并配置对象、给旧数据补充字段几乎是每时每刻都在做的事。很多人习惯顺手敲一行 Object.assign(target, source)，图个省事利落。等表单提交报错或状态视图突然跳动，才意识到这行代码背后藏着的“表面搬运”特性，正在悄悄篡改你的原始数据。把它掰开揉碎看明白，后面的代码才能跑得踏实。

Object.assign 的运行逻辑并不复杂，但它只做一件事：把源对象上所有可枚举的自身属性，按顺序直接赋给目标对象。基本数据类型（数字、字符串、布尔值）会完整复制一份新的内存空间；而引用类型（数组、纯对象、Date 实例）传递的仅仅是内存地址的引用。外层的键名覆盖没问题，一旦触及内部嵌套结构，新旧对象就会绑定在同一块堆内存上，牵一发而动全身。

写段实际代码就能直观感受。原始数据带着嵌套的用户档案，assign 复制后改动 newUser.profile.age，旧数据的年龄也会同步飙升。这不是框架抽风，而是浅拷贝的设计初衷。很多人误以为它等于全量克隆，结果在异步请求拦截、表单校验回滚或全局状态派发时频繁踩坑，定位问题往往要翻遍半个组件库。

看清机制后，使用策略就得跟上。划定使用边界，只针对扁平结构。如果你的业务对象已经拍平成单层键值对，assign 依然是性价比极高的选择，原生引擎层面的迭代速度远胜手写的 for...in 或 forEach。遇到多层嵌套需要独立副本时，可以直接用展开语法配合递归函数逐层拆开，或者在非关键路径上借用 JSON.parse(JSON.stringify(data)) 做一次性深拷贝。需要防止意外覆写，外层套一层 Object.freeze，内层按需解构，既能保住隔离性又不牺牲可读性。

别忽略两个容易翻车的隐形点。一是原型链属性与 Symbol 键会被自动过滤，如果下游逻辑强依赖这些隐藏字段，必须先用 Object.getOwnPropertyNames 或 Reflect.ownKeys 补齐；二是老环境运行时需要垫片支持，接入 CI 前跑一遍兼容性清单能省掉大量线上工单。把检测前置到编写阶段，比事后打补丁划算得多。

Object.assign 从来不是能抹平一切差异的橡皮擦，它更像一把尺寸固定的镊子。清楚它能精准夹起什么，也明确它碰不到哪片区域，数据流转的逻辑才会严丝合缝。下次再面对对象合并需求，先过一遍嵌套深度与共享引用风险，挑对动作，调试时间自然减半。