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 的判定时机**。用错场景，它不会帮你省事；用对地方，它能堵住几个隐蔽的浮点逻辑漏洞。
