3 同值相等
同值相等解决了最后一个用例：确定两个值是否在任何情况下功能上是相同的.
当试图对不可变（immutable）属性修改时发生出现的情况：
Object.defineProperty 在试图修改不可变属性时，如果这个属性确实被修改了则会抛出异常，反之什么都不会发生。例如如果 v 是 -0 ，那么没有发生任何变化，所以也不会抛出任何异常。但如果 v 是 +0 ，则会抛出异常。不可变属性和新设定的值使用 same-value 相等比较。
同值相等由 Object.is 方法提供。
4 零值相等
与同值相等类似，不过会认为 +0 与 -0 相等。
5 规范中的相等、严格相等以及同值相等
在 ES5 中， == 相等在 Section 11.9.3, The Abstract Equality Algorithm； === 相等在 11.9.6, The Strict Equality Algorithm。（请参考这两个链接，他们很简洁易懂。提示：请先阅读严格相等的算法）ES5 也提供了 same-value 相等， Section 9.12, The SameValue Algorithm ，用在 JS 引擎内部。除了 11.9.6.4 和 9.12.4 在处理数字上的不同外，它基本和严格相等算法相同。ES6 简单地通过 Object.is 暴露了这个算法。
我们可以看到，使用双等或三等时，除了 11.9.6.1 类型检查，严格相等算法是相等算法的子集因为 11.9.6.2–7 对应 11.9.3.1.a–f。
5 相等比较的模型
在 ES2015 以前，你可能会说双等和三等是“扩展”的关系。比如有人会说双等是三等的扩展版，因为他处理三等所做的，还做了类型转换。例如 6 == “6” 。反之另一些人可能会说三等是双等的扩展，因为他还要求两个参数的类型相同，所以增加了更多的限制。怎样理解取决于你怎样看待这个问题。
但是这种比较的方式没办法把 ES2015 的 Object.is 排列到其中。因为 Object.is 并不比双等更宽松，也并不比三等更严格，当然也不是在他们中间。从下表中可以看出，这是由于 Object.is 处理 NaN 的不同。注意假如 Object.is(NaN, NaN) 被计算成 false ，我们就可以说他比三等更为严格，因为他可以区分 -0 和 +0 。但是对 NaN 的处理表明，这是不对的。 Object.is 应该被认为是有其特殊的用途，而不应说他和其他的相等更宽松或严格。
6 何时使用 Object.is 或是三等
总的来说，除了对待NaN的方式，Object.is唯一让人感兴趣的，是当你需要一些元编程方案时，它对待0的特殊方式，特别是关于属性描述器，即你的工作需要去镜像Object.defineProperty的一些特性时。如果你的工作不需要这些，那你应该避免使用Object.is，使用===来代替。即使你需要比较两个NaN使其结果为true，总的来说编写使用NaN 检查的特例函数(用旧版本ECMAScript的isNaN方法)也会比想出一些计算方法让Object.is不影响不同符号的0的比较更容易些。
这里是一个会区别对待-0和+0的内置方法和操作符不完全列表：
(一元负)
显而易见，对0一元负操作得到-0。但表达式的抽象化可能在你没有意识到得情况下导致-0延续传播。例如当考虑下例时:
let stoppingForce = obj.mass * -obj.velocity
如果obj.velocity是0 (或计算结果为0), 一个-0就在上处产生并被赋值为stoppingForce的值.
即使传入的参数中没有-0，这些方法的返回值都有可能是-0。例如当用 Math.pow计算-Infinity的任何负奇指数的幂都会得到-0。详情请参见这些方法各自的文档。
当传入参数中有-0时，这些方法也可能返回-0。例如， Math.min(-0, +0) 得出 -0。详情请参见这些方法各自的文档。
这些操作符内部都使用了ToInt32算法。因为内部32位整数类型只有一个0（没有符号区别），-0的符号在反操作后并不会保留下来。例如Object.is(~~(-0), -0)和Object.is(-0 << 2 >> 2, -0) 都会得到false.
在未考虑0的符号的情况下依赖于Object.is是危险的。当然，如果本意就是区分-0和+0的话，Object.is能按照期望完成工作。
