这现在是ES6的一部分，因此是标准化的，并且在MDN上也有文档: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator

它使用起来非常方便，与对象解构一起使用也很有意义。

上面列出的另一个优势是object. assign()的动态功能，不过这就像在文字对象中展开数组一样简单。在编译后的babel输出中，它完全使用了Object.assign()所演示的内容

因此，正确的答案是使用object spread，因为它现在是标准化的，被广泛使用(参见react, redux等)，易于使用，并且具有object .assign()的所有特性。

这并不一定详尽无遗。

传播的语法

options = {...optionsDefault, ...options};

优点:

如果在没有本机支持的环境中编写代码以执行，则可以只编译此语法(而不是使用polyfill)。(比如巴别塔。) 可以减少复杂性。

缺点:

当这个答案最初被写出来的时候，这是一个建议，没有标准化。在使用提案时，请考虑如果您现在使用提案编写代码，而它没有得到标准化或在向标准化发展的过程中发生变化，该怎么办。这已经在ES2018中标准化了。 字面的，不是动态的。

Object.assign ()

options = Object.assign({}, optionsDefault, options);

优点:

标准化。 动态的。例子: var sources = [{a: " a "}， {b: " b "}， {c: " c "}]; options = Object.assign。应用(对象,({}).concat(来源)); / /或 options =对象。分配({},…来源);

缺点:

更详细的。 如果在没有本机支持的环境中编写代码执行，则需要填充。

这是让我疑惑的承诺。

这和你问的问题没有直接关系。这段代码没有使用Object.assign()，而是使用用户代码(object-assign)来做同样的事情。他们似乎在用Babel编译代码(并将其与Webpack捆绑)，这就是我所说的:你可以编译的语法。他们显然更喜欢这样，而不是必须将对象赋值作为一个依赖项包含到他们的构建中。

两者之间有着巨大的差异，并会带来非常严重的后果。投票最多的问题甚至没有触及到这一点，关于物体传播是一项提案的信息在2022年已经无关紧要了。

区别在于对象。赋值操作将对象就地更改，而展开操作符(…)将创建一个全新的对象，这将破坏对象引用相等性。

首先，让我们看看效果，然后我将给出一个现实世界的例子，说明理解这种根本差异是多么重要。

首先，让我们使用Object.assign:

// Let's create a new object, that contains a child object;
const parentObject = { childObject: { hello: 'world '} };

// Let's get a reference to the child object;
const childObject = parentObject.childObject;

// Let's change the child object using Object.assign, adding a new `foo` key with `bar` value;
Object.assign(parentObject.childObject, { foo: 'bar' });

// childObject is still the same object in memory, it was changed IN PLACE.
parentObject.childObject === childObject
// true

现在对展开运算符进行同样的练习:

// Let's create a new object, that contains a child object;
const parentObject = { childObject: { hello: 'world '} };

// Let's get a reference to the child object;
const childObject = parentObject.childObject;

// Let's change the child object using the spread operator;
parentObject.childObject = {
  ...parentObject.childObject,
  foo: 'bar',
}

// They are not the same object in memory anymore!
parentObject.childObject === childObject;
// false

很容易看出发生了什么，因为在parentObject上。childObject ={…}我们清楚地将parentObject中的childObject键的值赋给一个全新的对象文字，而它是由旧的childObject内容组成的事实是无关紧要的。这是一个新物件。

如果你认为这在实践中是无关紧要的，让我展示一个真实世界的场景来理解它有多重要。

在一个非常大的Vue.js应用程序中，当我们在输入字段中输入客户的名字时，我们开始注意到很多延迟。

经过大量调试后，我们发现输入中的每个字符都会触发一大堆需要重新计算的计算属性。

这是意料之外的，因为在那些计算函数中根本没有使用客户的名称。只使用了其他客户数据(如年龄、性别)。发生了什么事?当客户的名字改变时，vue为什么要重新计算所有这些计算函数?

我们有一家Vuex商店是这样做的:

mutations: {
  setCustomer(state, payload) {
    // payload being { name: 'Bob' }
    state.customer = { ...state.customer, ...payload };
  }

我们的计算是这样的:

veryExpensiveComputed() {
   const customerAge = this.$store.state.customer.age;
}

所以,瞧!当客户名称更改时，Vuex突变实际上是将其完全更改为一个新对象;由于计算依赖于该对象来获取客户年龄，Vue依赖于该非常特定的对象实例作为依赖项，当它被更改为一个新对象时(未能通过===对象相等性测试)，Vue决定是时候重新运行计算函数了。

这是固定的吗?使用对象。赋值不丢弃前一个对象，而是在适当的位置更改它…

mutations: {
  setCustomer(state, payload) {
    // payload being same as above: { name: 'Bob' }
    Object.assign(state.customer, payload);
  }

顺便说一句，如果你在ve2中，你不应该使用Object。因为Vue 2不能直接跟踪这些对象的变化，但同样的逻辑适用，只是使用Vue。set而不是Object.assign:

mutations: {
  setCustomer(state, payload) {
    Object.keys(payload).forEach(key => {
      Vue.set(state.customer, key, payload[key])
    })
  }

正如其他人所提到的，在撰写本文时，object .assign()需要一个polyfill和object spread…需要一些蒸煮(也许是一个填充)为了工作。

考虑下面的代码:

// Babel wont touch this really, it will simply fail if Object.assign() is not supported in browser.
const objAss = { message: 'Hello you!' };
const newObjAss = Object.assign(objAss, { dev: true });
console.log(newObjAss);

// Babel will transpile with use to a helper function that first attempts to use Object.assign() and then falls back.
const objSpread = { message: 'Hello you!' };
const newObjSpread = {...objSpread, dev: true };
console.log(newObjSpread);

它们都产生相同的输出。

下面是从Babel到ES5的输出:

var objAss = { message: 'Hello you!' };
var newObjAss = Object.assign(objAss, { dev: true });
console.log(newObjAss);

var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; };

var objSpread = { message: 'Hello you!' };
var newObjSpread = _extends({}, objSpread, { dev: true });
console.log(newObjSpread);

这是我目前的理解。object .assign()实际上是标准化的，其中随着对象扩展…还没有。唯一的问题是浏览器对前者以及未来对后者的支持。

玩一下这里的代码

希望这能有所帮助。

当你必须使用Object.assign时，我想添加这个简单的例子。

class SomeClass {
  constructor() {
    this.someValue = 'some value';
  }

  someMethod() {
    console.log('some action');
  }
}


const objectAssign = Object.assign(new SomeClass(), {});
objectAssign.someValue; // ok
objectAssign.someMethod(); // ok

const spread = {...new SomeClass()};
spread.someValue; // ok
spread.someMethod(); // there is no methods of SomeClass!

使用JavaScript时可能不清楚。但是如果你想创建一些类的实例，使用TypeScript会更容易

const spread: SomeClass = {...new SomeClass()} // Error

我想总结一下“扩展对象合并”ES特性在浏览器和工具生态系统中的状态。

Spec

https://github.com/tc39/proposal-object-rest-spread 这个语言特性是第4阶段的提案，这意味着它已经被合并到ES语言规范中，但还没有被广泛实现。

浏览器:Chrome, SF, Firefox(60版本，IIUC)

浏览器支持Chrome 60中附带的“传播属性”，包括这个场景。 在当前的Firefox(59)中不支持此场景，但在我的Firefox开发者版中可以。所以我相信它会在Firefox 60中发布。 Safari:未测试，但Kangax说它可以在桌面Safari 11.1中运行，但不适用于SF 11 iOS Safari:未测试，但Kangax说它可以在iOS 11.3运行，但不能在iOS 11运行 还没有在Edge中

工具:Node 8.7, TS 2.1

NodeJS从8.7开始支持(通过Kangax)。9.8在本地测试时确认。 TypeScript从2.1开始支持它，目前是2.8

链接

Kangax“财产蔓延” https://davidwalsh.name/merge-objects

代码示例(兼作兼容性测试)

var x = { a: 1, b: 2 };
var y = { c: 3, d: 4, a: 5 };
var z = {...x, ...y};
console.log(z); // { a: 5, b: 2, c: 3, d: 4 }

再次强调:在编写此示例时，无需编译即可在Chrome(60+)、Firefox Developer Edition (Firefox 60预览版)和Node(8.7+)中工作。

为什么答案?

我是在最初的问题提出两年半后写这篇文章的。但我也有同样的问题，谷歌让我来这里。我是SO改善长尾理论使命的奴隶。

Since this is an expansion of "array spread" syntax I found it very hard to google, and difficult to find in compatibility tables. The closest I could find is Kangax "property spread", but that test doesn't have two spreads in the same expression (not a merge). Also, the name in the proposals/drafts/browser status pages all use "property spread", but it looks to me like that was a "first principal" the community arrived at after the proposals to use spread syntax for "object merge". (Which might explain why it is so hard to google.) So I document my finding here so others can view, update, and compile links about this specific feature. I hope it catches on. Please help spread the news of it landing in the spec and in browsers.

最后，我本可以将这些信息作为评论添加进来，但我无法在不破坏作者原始意图的情况下编辑它们。具体来说，我无法编辑@ chillpenguin的评论，否则它就会失去纠正@RichardSchulte的意图。但多年后，理查德(在我看来)证明是对的。所以我写了这个答案，希望它最终能取代旧的答案(可能需要几年时间，但毕竟这就是长尾效应的意义所在)。