如何借助 Object.is 区分 +0 与 -0 并正确处理 NaN 的相等判断

Object.is 能区分 +0 和 -0，返回 false；对 NaN 也返回 true，而 === 均不满足。它严格按 IEEE 754 比较位模式，适用于需感知零符号或精准判 NaN 的场景，但不深比较对象，日常相等判断仍推荐 ===。

Object.is 能否区分 +0 和 -0

能，Object.is(+0, -0) 返回 false，这是它和 === 最关键的差异之一。JS 中 +0 === -0 为 true，但数学上二者符号不同；Object.is 严格按 IEEE 754 规则比较：+0 和 -0 的位模式不同（符号位相反），因此判为不等。

实操建议：

• 需要感知零的符号时（如坐标系、金融计算中区分“正向归零”与“负向归零”），必须用 Object.is，不能依赖 ===
• 检查是否为 -0：直接写 Object.is(x, -0)，比 1 / x === -Infinity 更直观安全
• 注意：Object.is(-0, 0) 也是 false，因为 0 字面量等价于 +0

Object.is 对 NaN 的处理为什么可靠

Object.is(NaN, NaN) 返回 true，而 NaN === NaN 是 false。这是因为 Object.is 不走抽象相等算法，而是直接比较两个值的内部表示 —— 所有 NaN 在 IEEE 754 中被视作“同一种不可比较值”，Object.is 显式规定它们相等。

实操建议：

• 校验计算结果是否意外产出 NaN（比如 Math.sqrt(-1) 或 0 / 0），用 Object.is(result, NaN) 比 isNaN() 或 Number.isNaN() 更精准（后两者会强制类型转换）
• 避免误用 result !== result 这种 hack 判 NaN 方式 —— 可读性差，且在某些调试器或优化场景下可能被干扰
• 注意：Object.is 不会把字符串 "NaN" 当作 NaN，只对真正的 NaN 值生效

什么时候不该用 Object.is 替代 ===

不是所有相等判断都需要语义更严格的 Object.is。它的行为在多数日常场景中反而“太严”。

常见问题点：

• 对象或数组比较仍返回 false（和 === 一样），因为它不递归深比较，别指望它替代 _.isEqual 或 JSON.stringify 方案
• 字符串、数字、布尔等基本类型在绝大多数业务逻辑里用 === 完全够用，引入 Object.is 反而增加认知负担
• 性能上，Object.is 略慢于 ===（V8 中约慢 10%~15%，因多一层符号位/NaN 特殊判断），高频循环中需权衡
• 兼容性没问题（ES6+ 全支持），但若需跑在极老环境（如 IE），得加 polyfill 或降级到 === + 手动补零/NaN 判断

一个实用的工具函数封装建议

直接裸用 Object.is 容易漏掉边界，建议按需封装成带意图的判断函数：

const isNegativeZero = (val) => Object.is(val, -0);const isNaNValue = (val) => Object.is(val, NaN);const isSameZero = (a, b) => {  if (!Object.is(a, b)) return false;  // 此时 a 和 b 已相等，但若都是 0，还需确认符号一致  return !Object.is(a, +0) || !Object.is(b, -0) || Object.is(a, b);};

注意：最后这个 isSameZero 示例看似绕，其实暴露了关键点 —— Object.is 的真正价值不在“通用相等”，而在**精确控制 +0/-0 和 NaN 的判定时机**。用错场景，它不会帮你省事；用对地方，它能堵住几个隐蔽的浮点逻辑漏洞。