企业官网建设流程全解析

做前端久了你会发现，处理对象拷贝和合并这件事，几乎天天都在写，但大部分人只是习惯性地敲出{ ...obj }或者Object.assign({}, obj)，从来没仔细想过这俩到底有什么区别。我之所以专门研究这个问题，是因为某次在一个状态管理的重构项目里，同事把Object.assign直接当深拷贝用，结果嵌套对象改一处、所有引用全跟着变，线上排查了大半天才定位到原因。从那次之后，我花了不少功夫把扩展运算符和Object.assign的规范语义、实际行为、性能细节从头到尾捋了一遍，今天干脆把这些内容完整地分享出来。

这篇内容适合三类人：刚入行不久、总是分不清扩展运算符和 assign 的新人；写了几年业务、想在状态管理和组件封装里减少隐性 bug 的前端；还有想系统梳理一遍 JS 对象合并知识点的中高级开发者。看完之后你至少能掌握：两者各自的适用边界、底层执行语义差异、常见业务坑位，以及一份可以直接抄走的速查表。

先别急着写代码，我们从最初的设计意图说起。

1. 先搞清楚这两个东西到底解决什么问题

1.1 扩展运算符的诞生背景与设计初衷

很多人以为扩展运算符天生就是用来合并对象的，其实它最早的目标是函数调用和数组操作。ES5 时代，想把一个数组的元素传给函数，只能写Math.max.apply(null, arr)；想拼接数组，只能写arr1.concat(arr2)。这些写法没问题，但读起来总隔了一层。扩展运算符的初衷就是把"把数组展开成参数"这件事变成语法本身，于是就有了Math.max(...arr)、[...arr1, ...arr2]。

这里有个关键点：在数组和函数调用场景里，扩展运算符依赖的是迭代协议。也就是说，只有实现了Symbol.iterator的东西才能被展开。数组、字符串、Set、Map 都实现了迭代器，所以[...new Set([1,2,3])]、[...'hello']都能正常跑起来。

后来规范把扩展运算符扩展到了对象字面量里，比如{ ...obj }。对象展开走的路径跟数组展开完全不同——它不依赖迭代协议，而是直接枚举源对象的可枚举自有属性。这一点极其重要，因为很多人拿[...{a:1}]试试发现报错，就以为对象展开和数组展开是一回事，其实只是规范里重用了同一个语法符号，底层机制并不相同。

1.2 Object.assign 的设计初衷

Object.assign是 ES6 同期加入的静态方法，定位非常明确：把多个源对象的可枚举自有属性复制到目标对象上。它的核心行为可以拆成四步：

1. 把目标对象转成对象类型，null和undefined在这里会直接抛错。
2. 依次遍历每个源对象。
3. 对源对象里的每个可枚举自有属性键，读取其值，然后写到目标对象上。
4. 返回目标对象本身。

这个方法的出现，本质上是为了替代早期各种第三方库里的extend工具方法。以前用 jQuery 有$.extend，用 Underscore 有_.extend，用 Lodash 有_.assign，干的事情基本都一样——把一个对象的属性拷贝到另一个对象上。Object.assign进了标准库之后，这种操作不用再依赖外部依赖，同时也给后来前端状态管理的不可变更新风格打了一个基础。

有一点很多人不知道：Object.assign的提案时间和扩展运算符非常接近，两者在设计语义上是互相影响的。所以你会看到它们处理对象拷贝时的行为高度相似，甚至规范里对象展开使用的抽象操作CopyDataProperties也和Object.assign的赋值逻辑同源。但它们最大的分岔点，恰恰藏在"要不要修改目标对象"这一层。

1.3 一句话记住两者差异

我的经验总结是这样：扩展运算符默认是"我要一个新对象"，Object.assign 默认是"我要往现有对象身上填东西"。

这个差异决定了 90% 的场景选谁。比如在函数式状态更新里，你永远不希望原状态被顺手改掉，那扩展运算符就是更安全的默认项；而在某些缓存合并、多源数据落地的场景里，你可能确实希望在一个已存在的对象上不断追加属性，那Object.assign反而更顺手。

2. 展开语法与 Object.assign 的正面交锋

2.1 对象合并：写法差异与行为差异

先说最基本的对象合并。看这段代码：

const obj1 = { a: 1, b: 2 }; const obj2 = { b: 3, c: 4 }; const spreadResult = { ...obj1, ...obj2 }; const assignResult = Object.assign({}, obj1, obj2); console.log(spreadResult); // { a: 1, b: 3, c: 4 } console.log(assignResult); // { a: 1, b: 3, c: 4 }

结果一样，都是后者覆盖前者。但如果你把Object.assign的目标对象从{}换成obj1，行为立刻不同：

const mutated = Object.assign(obj1, obj2); console.log(mutated === obj1); // true console.log(obj1); // { a: 1, b: 3, c: 4 }

obj1被原地改掉了。扩展运算符则没有这种副作用，{ ...obj1, ...obj2 }永远产生新对象，源对象不受影响。

这个差异在业务代码里经常被忽略。我见过不少 reducer 或状态管理代码里写Object.assign(state, { loading: true })，一旦 state 对象被组件引用，就容易触发各种"我明明没改它，它怎么变了"的灵异现象。改成{ ...state, loading: true }之后，整个更新流程立刻清晰起来。

另外要注意，Object.assign对多个源对象的处理是顺序覆盖，后面的源对象优先级更高。扩展运算符的顺序由对象字面量本身决定，而且可以和普通键值对混着写：

const merged = { ...sourceA, ownKey: 1, ...sourceB };

这里的执行顺序一目了然：先展开 sourceA，再定义 ownKey，最后展开 sourceB。如果 sourceB 里有 ownKey 同名属性，会覆盖前面的值。

2.2 数组拼接与复制：扩展运算符的独门绝技

数组处理是Object.assign基本帮不上忙的地方，也是扩展运算符最大的优势区。

数组拼接：

const arr1 = [1, 2, 3]; const arr2 = [4, 5, 6]; const combined = [...arr1, ...arr2]; // [1, 2, 3, 4, 5, 6]

数组复制：

const original = [1, 2, 3]; const copyViaSpread = [...original]; const copyViaSlice = original.slice();

两种复制都是浅拷贝，元素是基本类型时完全等价。但注意一个细节：扩展运算符复制的是迭代过程，遇到稀疏数组的空位时会把它当作undefined来访问，也就是说稀疏数组展开之后会变成密集数组。slice则会把空位原样保留。这个差异平时不太明显，但如果你的数据里存在大量空位，比如从 CSV 或某些外部接口拿到的稀疏数组，copyViaSpread和copyViaSlice的结果就不同了。

配合 Set 做去重或者配合 Map 做键值对数组转换，也是扩展运算符的常用姿势：

const unique = [...new Set([1, 2, 2, 3])]; // [1, 2, 3] const pairs = [...new Map([['a', 1], ['b', 2]])]; // [['a', 1], ['b', 2]]

因为 Set 和 Map 都实现了迭代器，这套写法几乎成了现代前端处理集合类的默认风格。

2.3 字符串展开的隐藏细节

字符串也是可迭代对象，所以[...'hello']会得到['h', 'e', 'l', 'l', 'o']。很多人觉得这只是个花哨技巧，但它在处理 Unicode 字符时有一个实打实的优势。

JavaScript 字符串的length是按 UTF-16 码元计算的，一个 emoji 比如'😀'的长度是 2，因为它占两个码元。如果你用str.split('')去拆一个 emoji 字符串，会得到两个乱码字符。而扩展运算符走的是字符串迭代器，迭代器按码点产出，所以：

const text = 'a😀b'; console.log(text.length); // 4 console.log([...text]); // ['a', '😀', 'b']

这是处理多语言、emoji、生僻字场景时非常实用的一招。Object.assign处理字符串时表现就差很多了，因为它把字符串当成类数组对象来拷贝索引属性：

console.log(Object.assign({}, 'ab')); // { 0: 'a', 1: 'b' }

这种结果在大多数业务场景里没有意义，所以遇到"把字符串拆成字符数组"这类需求，优先想到扩展运算符就对了。

2.4 函数调用与 rest 参数中的逆用

扩展运算符不只是字面量语法，它在函数调用里也一样能做到"展开参数"的效果。最经典的例子是求最大值：

const numbers = [5, 42, 17, 8]; const max = Math.max(...numbers); // 42

以前需要Math.max.apply(null, numbers)，现在一行搞定。另一个经常被关联起来讲的是 rest 参数，它和扩展运算符共用三个点符号，一个负责收起，一个负责展开：

const [first, ...rest] = [1, 2, 3, 4]; console.log(first); // 1 console.log(rest); // [2, 3, 4]

注意 rest 参数必须是最后一位，而且只能用于解构赋值或函数参数声明，不能单独出现在表达式里。它跟扩展运算符的方向相反，本质上是"把剩下的所有东西打包成一个数组"。在写函数参数数量不确定的工具函数时，rest 参数配合扩展运算符几乎是标配方案。

3. 底层原理与执行语义的深入拆解

3.1 迭代协议与可枚举性

扩展运算符在不同的场景下依赖不同的底层机制，这是理解它行为边界的关键。

在数组字面量和函数调用场景，扩展运算符会尝试调用对象的Symbol.iterator方法。没有这个方法的对象，比如普通对象{ a: 1 }，在数组里展开会直接报错：

try { const arr = [...{ a: 1 }]; } catch (error) { console.log(error.message); // object is not iterable (cannot read property Symbol(Symbol.iterator)) }

相反，在对象字面量里展开数组是完全可以的，因为数组的索引属性本身是可枚举的自有属性：

const obj = { ...[1, 2, 3] }; console.log(obj); // { 0: 1, 1: 2, 2: 3 }

这里走的是属性枚举，跟迭代器没有任何关系。所以不要试图用"它能不能被展开"来推断对象实现了什么协议，要分清楚你是在数组场景、函数调用场景还是对象字面量场景里使用扩展运算符。

可枚举性也是很关键的一环。无论是对象展开还是Object.assign，都只管可枚举的自有属性。什么意思？就是你手动赋值给对象的属性，默认可枚举，但通过Object.defineProperty创建的属性可以设置为enumerable: false，这两种方式都不会拷贝它：

const source = { visible: 1 }; Object.defineProperty(source, 'hidden', { value: 2, enumerable: false }); console.log({ ...source }); // { visible: 1 } console.log(Object.assign({}, source)); // { visible: 1 }

原型链上的属性同样不会被拷贝，因为它们不是自有属性。这个约束保证了浅拷贝的语义边界清晰，但如果你确实想拷贝继承来的属性，扩展运算符和Object.assign都做不到，需要自己遍历原型链或用别的手段。

3.2 赋值语义：写入过程完全不同

扩展运算符和Object.assign最核心的原理差异，出在"写入"这一步。

Object.assign内部对目标对象的赋值走的是[[Set]]语义。这意味着如果目标对象上已经存在一个同名属性，而这个属性有 setter，那么Object.assign会触发这个 setter，可能会执行额外的逻辑。

举一个例子：

const target = { set count(value) { this._count = value * 2; } }; Object.assign(target, { count: 5 }); console.log(target._count); // 10

这里可以看到，Object.assign并没有直接把count写为 5，而是通过 setter 间接赋值为 10。这在某些需要校验或转换的场景里算是个特性，但也意味着行为不透明，容易出bug。

对象字面量展开走的则是定义属性的语义，内部类似CreateDataProperty或DefineProperty，它不会触发目标对象上的 setter，而是直接创建或重新定义这个属性：

const spreadTarget = { set count(value) { this._count = value * 2; } }; const next = { ...spreadTarget, count: 5 }; console.log(next); // { count: 5 }，没有触发 setter，也没有 _count

差异的根源是：Object.assign是"通过赋值操作写入"，扩展运算符是"通过属性定义写入"。你可以把前者理解为给已有的抽屉换东西，可能会触发抽屉自带的机关；后者是直接往新抽屉里塞东西，不碰任何机关。

这个差异在业务里比较隐蔽，但遇到一些通过 setter 做数据驱动的组件时尤其值得警惕。我甚至见过有人把Object.assign写在一个带 setter 的对象上，结果每次合并都会触发this._xxx的值被改写，导致渲染异常。

3.3 浅拷贝的边界与引用共享

无论是展开运算符还是Object.assign，拷完之后得到的都是浅拷贝。也就是说，对象的第一层属性是新的，但属性值如果是引用类型，那拷贝出来的对象和原对象会共享同一个内层引用。

const source = { name: 'demo', config: { theme: 'dark' } }; const viaSpread = { ...source }; const viaAssign = Object.assign({}, source); viaSpread.config.theme = 'light'; console.log(source.config.theme); // 'light' console.log(viaAssign.config.theme); // 'light'

这里viaSpread.config和source.config指向同一个对象，所以改一个，全部跟着变。很多人把这个误当成深拷贝来用，这是我在各种项目里最常见的错误。

要真正实现深拷贝，至少有三种常见思路：

• 使用结构化克隆算法，浏览器环境下structuredClone就是标准方案。
• 使用 JSON 序列化JSON.parse(JSON.stringify(obj))，但会丢失undefined、函数、symbol键以及循环引用。
• 自己写递归拷贝函数，注意处理数组、日期、正则、Map、Set 等特殊类型。

这三种方案各有取舍，按业务需求来。但有一点要记住：如果数据里有循环引用，JSON 方案直接报错；如果数据量巨大，递归方案可能栈溢出。structuredClone是最稳妥的默认选择，只不过兼容性要自己评估。

3.4 属性描述符与特殊键的处理差异

讲到属性层面，还有一个容易被忽略的坑：拷贝之后，属性描述符会丢失。

源对象的某个属性如果是通过Object.defineProperty定义的，并且是只读的、不可枚举的，那么拷贝后这个属性的描述符不会原样保留。因为无论是扩展运算符还是Object.assign，拷贝的都是"属性的值"，而不是"属性的完整描述"。

举个例子：

const source = {}; Object.defineProperty(source, 'locked', { value: 1, writable: false }); const next = { ...source }; next.locked = 2; console.log(next.locked); // 2，拷贝出来的属性是可写的

这符合大多数业务预期，因为你要的就是数据快照，而不是描述符快照。但如果你的场景对属性描述符有要求，比如要拷贝一个带 getter 的配置对象，那这两种方式都不会保留原始的 getter 函数，而是把 getter 求值后的结果作为一个普通数据属性写进去。

另一个更隐蔽的坑是特殊键__proto__。Object.assign在赋值时走[[Set]]，如果目标对象对__proto__有特殊处理，可能引发原型链修改：

const parsed = JSON.parse('{"__proto__": {"polluted": true}}'); // 这里 Object.assign 在某些环境下可能污染原型 Object.assign({}, parsed);

对象字面量展开则更安全，因为它是通过定义属性的方式写入的，不会触发__proto__的 setter，因此不会直接修改原型链。这里我不展开讲原型污染攻击的具体细节，但你可以记住一个结论：在合并外部不可信 JSON 数据时，使用对象展开比使用Object.assign更稳一点。

4. 常用场景的代码实践与性能考量

4.1 不可变状态更新的标准写法

在前端状态管理场景，不可变更新几乎是基本规范。最典型的就是 reducer 模式：每次更新都返回一个新对象，而不是修改旧 state。

使用扩展运算符的写法非常自然：

const state = { user: { name: 'A', age: 18 }, loading: false }; // Action: 更新 age const nextState = { ...state, user: { ...state.user, age: 19 } };

这种写法保证了state对象本身不被修改，而nextState和state会共享user.name之外的结构。如果要更新嵌套几层的属性，每一层都要展开一次，写起来确实繁琐，但胜在规则简单、不容易出意外。

Object.assign在这里也可以实现不可变更新，但不能直接拿原 state 当目标对象，需要配合空对象使用：

const nextState = Object.assign({}, state, { user: Object.assign({}, state.user, { age: 19 }) });

对比之下，扩展运算符的嵌套写法更直观。所以我的建议是：在状态管理、函数式组件、纯函数更新这些场景里，默认选择扩展运算符。

4.2 数据快照与缓存合并

也有适合Object.assign的场景。比如你想在一个已有对象上持续追加多个来源的数据，而且希望最终稳定持有同一个引用。典型的是缓存对象或配置对象：

const cache = { baseUrl: '/api' }; function updateCache(patch) { Object.assign(cache, patch); }

这里cache引用保持不变，其他模块持有这个引用也能同步看到变化。如果用扩展运算符，就得不断重新赋值给cache变量，但持有旧引用的模块依然看不到更新。所以在"保持引用不变"的前提下，Object.assign是比扩展运算符更合适的工具。

另一个适用场景是批量合并多个配置源。Object.assign({}, defaultConfig, userConfig, envConfig)这种三段式配置合并，在工具函数里非常常见，比嵌套多层展开简洁不少。

4.3 关于性能：到底谁更快

这个问题被问过很多次。在 V8 和主流 JavaScript 引擎里，扩展运算符和Object.assign的性能差距其实没有想象中大。如果你只合并两个小对象，性能差异完全可以忽略。

我确实在某个维护项目里做过简单的规模测试，数据量在几万条对象的情况下，两者的耗时差距基本在个位数百分比内。真正影响性能的往往是后面的浅拷贝深度、源对象属性数量、引擎优化状态等。所以选型时优先考虑语义是否合适，而不是纠结那点微耗时。

不过有一个性能相关的方向要注意：Object.assign可以复用目标对象，减少一次对象分配。在极端高频的写路径里，比如每帧处理一组数据合并，复用一个 pre-allocated 对象可能比每次{ ... }创建新对象更友好。但现代引擎对短期对象分配优化得相当好，这个优化空间的优先级并不高。

4.4 与解构赋值的组合用法

先看 rest 和解构配合对象场景：

const { a, ...others } = { a: 1, b: 2, c: 3 }; console.log(a); // 1 console.log(others); // { b: 2, c: 3 }

这是"排除某个字段"的标准姿势。比如接口返回的数据里有很多冗余字段，你想剔除id再传给子组件，直接解构取出不需要的字段，剩下的结构就是干净的 payload。

再看函数参数中的 rest 和解构配合：

function formatUser({ name, ...rest }) { return { displayName: name.toUpperCase(), ...rest }; }

这种写法在组件封装、DTO 转换里非常好用。既保留你关心的字段，又让其他字段原样透传。相比手动删除某个键，这种方式可读性高得多。

5. 踩坑实录与常见问题速查

5.1 浅拷贝共享引用引发的连锁修改

这是使用这两种方式最经典的坑。

我在某个项目里遇到过一个 bug：表格组件收到一批过滤后的数据，组件内用{ ...props.rowData }复制了当前行数据，然后修改了复制对象的某个字段。结果原表数据也跟着变了。原因就是该字段是一个对象引用，浅拷贝只复制了引用本身，没有复制内层对象。

这个问题的排查思路很简单：先检查被修改的属性是不是引用类型，如果是，就得考虑内层也展开一次，或者直接使用深拷贝。写扩展运算符时要有意识地问自己：这个属性值里有引用类型吗？如果有，浅拷贝够不够？

5.2 null 和 undefined 作为源对象的行为

扩展运算符处理null和undefined非常宽容，在对象展开时会直接忽略：

const safeSpread = { ...null, ...undefined }; console.log(safeSpread); // {}

而Object.assign遇到null或undefined作为源对象时会直接抛出 TypeError：

try { Object.assign({}, null, undefined); } catch (error) { console.log(error.message); // Cannot convert undefined or null to object }

如果你写了一个通用的合并函数，参数可能是可选的，那么Object.assign的这个行为需要额外防御。可以用{}给默认值，或者在调用前过滤掉 null/undefined。相比之下，扩展运算符在对象展开场景没有这个烦恼。

5.3 数组空位与稀疏数组的拷贝差异

前面提到过，扩展运算符迭代数组时会把空位访问一遍，得到的数组是密集的；slice保持空位不变。举个例子：

const sparse = [1, , 3]; const spreadCopy = [...sparse]; const sliceCopy = sparse.slice(); console.log(spreadCopy); // [1, undefined, 3] console.log(sliceCopy); // [1, <empty>, 3] console.log(0 in spreadCopy); // true console.log(0 in sliceCopy); // true console.log(1 in spreadCopy); // true console.log(1 in sliceCopy); // false

这个差异在处理稀疏数组时会造成一些微妙影响，比如map在空位上会跳过元素，而[...sparse]之后map就不会跳过了。如果你从某些外部数据源拿到的是稀疏数组，建议先用 Array 的flatten标准方法或Array.from显式处理，不要依赖展开运算符的隐式行为。

5.4 symbol 键与不可枚举属性的拷贝黑区

Object.assign和对象展开都会拷贝可枚举的 symbol 键属性。这听起来很全面，但有个前提：属性必须可枚举、必须是自有属性。

如果你的源对象里有不可枚举属性，或者属性在原型链上，那么这两种方式都会漏掉。这在处理一些内置对象时会很明显，比如你复制一个Set或Map，得到的不是可用的集合类型，而是一个空对象，因为它们的内部槽位根本不会通过属性枚举暴露出来。

所以时刻记住：对象的展开和合并都是数据搬运，不是类型转换。你要拷贝什么类型的对象，最好用专门的方法，而不是{ ...obj }一把梭。

5.5 常见问题速查表

6. 几个值得单独说说的边界场景

6.1 用扩展运算符与 Map、Set 的组合

对象合并场景里，Map 和 Set 也是常见的可迭代对象。在数组字面量里，[...map]会把 Map 展开成一个个[key, value]数组；在对象字面量里展开 Map 则不会得到键值对对象，因为 Map 默认没有可枚举的自有属性，{ ...map }得到的是一个空对象。

这算是一个容易出错的点。如果你想把 Map 转成普通对象，不能直接写{ ...map }，而要先Object.fromEntries(map)：

const map = new Map([['a', 1], ['b', 2]]); console.log({ ...map }); // {}，不对 console.log(Object.fromEntries(map)); // { a: 1, b: 2 }，正确

Object.fromEntries是 ES2019 的标准方法，专门做 Map 转对象的事。它和Object.entries正好是逆操作。记住这个组合，能避开不少奇怪的坑。

6.2 对象展开的嵌套改写与不可变性

嵌套对象更新时，很多人会写出这样的代码：

const state = { nested: { count: 0 } }; const next = { ...state, nested: { count: state.nested.count + 1 } };

这里next.nested是一个新对象，state.nested没有被修改，因此不可变性是维护住的。但如果某个人图省事，直接state.nested.count = 1，那所有的引用就都乱了。所以团队的代码规范里，可以明确写一条：在状态更新相关的代码中，嵌套对象必须逐层展开后再赋值，禁止直接改引用内部属性。

6.3 展开运算符处理多层级配置的取舍

多层配置合并时，展开运算符的铺展深度其实是有限的。比如你要合并一个多层配置对象，直接用{ ...defaults, ...user }只会覆盖第一层，第二层的对象会被整个替换，而不是逐字段合并。

如果需求是深合并，比如保留默认配置的 B 字段，同时只覆盖用户传进来的 A 字段，那就不能靠展开运算符了，得写递归合并或者引入工具库。这也是很多人在配置合并场景踩坑的点：看到第一层合并成功，就以为整个配置都按需合了，结果某个子配置整体被覆盖。

7. 我的选型心得与后续建议

说实话，在我接触的绝大多数业务代码里，扩展运算符都是更合适的默认选择。它产生的副作用更少，语义更贴近现代函数式风格，写法也更简洁。

但有三个场景我会主动选择Object.assign：

一是需要复用同一个目标对象并保持引用稳定，比如全局配置对象的持续追加；二是希望利用它触发目标对象 setter 的特性，虽然这种场景非常少；三是团队里某些旧代码还没用上展开运算符，需要保持代码风格一致。

还有一个使用习惯想分享。无论选哪种，写完之后多看一眼：你是在"拷贝数据"还是在"迁移引用"？如果答案是前者，且数据里有嵌套结构，尽快确认是否需要深拷贝。这个习惯救了我很多次，也希望能帮你在项目里少加点班。

如果你正在做一个数据流比较复杂的项目，我建议花半小时专门把代码里所有的Object.assign和{ ... }都搜出来，逐个确认目标对象是否会被意外修改、嵌套引用是否共享、特殊键是否有风险。这个过程排查出来的问题，往往比新加功能时遇到的 bug 更有价值。