前端项目里，Object.is 并不是 === 的平替

最近重构老项目的时候，看到同事写的一段判断逻辑，直接把 === 换成了 Object.is，本意是想规避 0 和 -0 的坑，结果在一处状态对比上出了小 bug。

之前我也一直简单记着：Object.is 修复了 === 的两个怪异点，NaN === NaN 是 false，但 Object.is(NaN, NaN) 为 true；0 === -0 是 true，但 Object.is(0, -0) 是 false。很多教程一笔带过，实际业务里很容易忽略这个差异带来的问题。

先贴两段简单对比代码：

复制代码

console.log(NaN === NaN); // false
console.log(Object.is(NaN, NaN)); // true

console.log(0 === -0); // true
console.log(Object.is(0, -0)); // false

出事的场景是这样的：我们有一个进度计算，后端返回的进度在边界条件下会算出 -0，前端拿这个值和 0 对比，用来判断是否重置进度条。

原来的代码用 ===，一直没问题：

复制代码

// 旧代码
if (progress === 0) {
  resetProgress()
}

同事改成下面之后，进度为 -0 的时候，判断直接失效，重置逻辑不会执行：

复制代码

// 有问题的写法
if (Object.is(progress, 0)) {
  resetProgress()
}

排查的时候一开始没往这方面想，日志打印看着都是 0，断点仔细看才发现一个是 0，一个是 -0。

很多人会有一个误区：觉得 Object.is 比三等号更严谨，所有场景都优先用它。其实不是，它只是一套不一样的相等判断规则，不存在绝对的谁更好。

简单梳理适用场景：

需要判断 NaN 的时候，Object.is 很顺手，不用写 Number.isNaN() 嵌套；

// 判断是不是NaN
const val = getSomeComputeResult()
if (Object.is(val, NaN)) {
// 处理非法计算值
}
业务上明确要区分正零和负零 ，比如一些数学计算、坐标、向量相关场景，才适合用 Object.is；
绝大多数普通业务状态判断、接口字段对比，老老实实 === 就足够，没必要强行替换。

顺带提一下，这和 == 完全不是一回事，Object.is 和 === 一样不会做隐式类型转换。

复制代码

console.log(Object.is('1', 1)); // false
console.log('1' === 1); // false

最后我这边的修复方案没有回退全部 Object.is，而是单独对进度这一处做兼容：

复制代码

if (Object.is(progress, 0) || Object.is(progress, -0)) {
  resetProgress()
}

或者更稳妥一点，先转成数字再处理边界：

复制代码

const realProgress = Math.abs(progress)
if (realProgress === 0) {
  resetProgress()
}

这个坑不算大，属于 JS 语言底层的历史特性。平时写业务很少碰到 -0，一旦遇上，这种隐蔽的差异特别耗排查时间。

写在这里也算记录一下：不要无脑跟风替换相等判断，先想清楚，业务到底要不要区分 0 和 -0。

有没有小伙伴在 canvas、图形计算或者数值运算里踩过正负零的坑？