object.assign() 不适合大批量合并，应避免循环调用；推荐对象复用+显式赋值、分片处理、惰性计算及专用深度合并方案。
Object.assign() 本身不优化大批量合并的性能，反而在数据量大时容易加剧内存压力和耗时——它会创建新对象、浅拷贝所有可枚举属性、触发大量临时对象分配。真正有效的优化不是“怎么用 Object.assign”，而是“什么时候不该用它”，以及用更轻量、可控的方式替代。
避免在循环中高频调用 Object.assign()
常见反模式：遍历数千条记录，每条都 Object.assign({}, base, item) 合并生成新对象。
- 每次调用都新建对象，GC 压力陡增，尤其在 Node.js 长期内存场景下易触发频繁垃圾回收
- 浅拷贝对嵌套结构无效，若业务实体含深层配置（如
user.profile.address），合并后仍共享引用，后续误改引发隐性 bug - 实际耗时大头常不在赋值本身，而在 V8 对临时对象的分配 + 后续 GC 停顿
用对象复用 + 显式赋值替代无脑合并
若目标是将字段“注入”或“补全”到已有实体（如从 DB 查出基础数据，再叠加缓存/配置字段），优先复用原对象：
- 直接遍历 key 赋值：
for (const k in patch) target[k] = patch[k]，零额外对象开销 - 配合
Object.hasOwnProperty.call(patch, k)过滤原型链属性，比Object.keys(patch).forEach(...)更快且安全 - 对固定结构业务实体（如订单、用户），可预编译赋值函数（用
new Function或构建器），跳过运行时 key 枚举
批量合并时启用结构化分片与延迟计算
当必须产出全新对象集合（如响应 DTO 转换），避免单次处理全部数据：
- 按 100–500 条为一批分片处理，每批后主动
await Promise.resolve()让事件循环交还控制权，缓解主线程阻塞 - 对非立即需要的字段（如统计摘要、格式化时间），改为 getter 或惰性计算属性，首次访问才生成，降低初始内存占用
- 使用
Object.defineProperties(target, descriptors)批量定义属性，比多次.xxx = yyy略高效（V8 优化友好）
深度合并场景坚决弃用 Object.assign()，改用专用方案
若业务要求真正合并嵌套对象（如配置叠加、模板继承），Object.assign() 完全失效：
- 手写轻量递归合并函数，控制递归深度、跳过 null/undefined、支持数组合并策略（覆盖 or concat）
- 引入成熟库如
lodash.merge（注意只 import merge 单函数，避免打包全量 lodash） - 对超大规模（>10k）且结构高度一致的数据，考虑用
Array.prototype.map+Object.create(null)创建无原型对象，减少属性查找开销
关键不是替换一个 API，而是厘清合并意图：是补全字段？构造视图？还是配置叠加？根据目的选最窄、最可控的实现路径。Object.assign 是便利语法糖，不是高性能原语。
