先给结论NaN和NaN用比较是false这不是 bug而是浮点标准里“NaN 不等于任何值包括自身”的规则。但到了业务代码里这条规则就非常折磨人。我前阵子写一个同步缓存模块拿新旧配置做比较只要配置里包含NaN缓存命中率直接归零。排查到最后问题就出在我还在用判断相等。今天想聊的这套更严格的相等性判断 API就是希望解决这类“表面相等、实际不相等”的问题你不再需要靠和打补丁而是把NaN、-0、深层对象这些边角情况全部交给专门 API 处理。适合被深比较坑过、或者想搞清楚 JS 相等性语义的读者。注意不同环境对这套 API 的命名不完全一致有的叫isDeepStrictEqual有的叫isStrictEqual有的老工具库干脆叫isEqual。为了避免绑定某个具体名称这篇文章统一用isStrictEqual代称这类 API核心思路是一样的更严格、更完整的相等性判断。下面我从传统比较方式的缺陷讲起再把 API 的规则、用途、选型和避坑慢慢拆开。1. 为什么已经不够用了1.1 先看传统方案留下的三个坑很多人写 JavaScript 比较的逻辑第一反应是“别用用”。这个建议在大方向上没错因为会做隐式类型转换0 是true1 true也是true非常容易掩盖类型错误。我在自己的项目规范里也长期禁用了。真正的问题是并没有大家想象的那么严格它至少会漏掉三类场景。第一个坑就是开头提到的NaN。NaN NaN返回false这是语言规范层面的决定目的是让相等判断符合浮点运算里“NaN 不等于任何数”的约定。问题是真实业务里NaN完全可能作为合法数据存在。比如你求平均值结果可能是NaN你用这个值去和上一次结果做比较希望判断缓存是否命中会稳定地返回 false于是缓存永远不会命中。这不是数学问题是相等语义和业务语义不匹配。第二个坑是0和-0。0 -0在 JavaScript 里是true但很多场景里这两个数不该等同。比如方向、位移、某些数值计算的符号位都依赖正负零的区分。你用1 / 0得到正无穷用1 / -0得到负无穷结果完全相反。如果比较环节直接把它们当同一个数后面整个计算链都会悄悄出错而且特别难排查因为日志里打印出来都是0。第三个坑是对象比较。{} {}是false因为对对象只比较引用不比较内容。哪怕两个对象字段一模一样、嵌套结构一模一样只要不是同一个内存地址一律返回 false。于是很多人只能自己写递归遍历去比较结果一会儿漏掉数组一会儿漏掉 Date一会儿原型链处理错最后每个项目里都有一份残缺不全的深比较实现。这三个坑本质上是不同的相等语义造成的。走的是宽松相等经过类型转换和对象转原始值走的是严格相等不做类型转换但内部仍然默认NaN不相等、0和-0相等。而我们真正想要的往往是“要么原始值语义完全一致要么对象内容完全一致”的更严格判断。这里可以打个生活化的比方是看到两个人穿了同款外套就认为相同是看身份证号是否相同Object.is是比对 DNA而严格深比较则是把你俩从出生到现在经历的所有细节核一遍。1.2 SameValue、SameValueZero、深度相等到底差在哪JavaScript 语言内部其实不止一种相等语义。除开和规范里还有SameValue和SameValueZero两个概念前者对应Object.is后者是 Map、Set 判断键是否相等时使用的规则。我需要先说清楚它们之间细微的区别这决定了后面 API 的行为。SameValue与最大的不同有两点一是NaN与自身相等二是0与-0不相等。SameValueZero比SameValue稍微宽松一点它仍然认为NaN等于NaN但0和-0是相等的这也是 Map 内部不希望把0和-0拆成两个键的原因。等到了严格相等性判断 API 这里思路就是把这些语义扩展到对象、数组、Date、Map、Set 等结构化数据上递归判断两个值在每一层是否更严格地相等同时为内建对象提供符合直觉的比较规则。我用一个表格把这几种语义列出来方便对照比较语义是否做类型转换NaN NaN0 -0对象比较方式宽松相等会false相等转换后比较严格相等不会false相等只比较引用Object.isSameValue不会true不相等只比较引用Map/Set 内部SameValueZero不会true相等只比较引用严格相等性判断 API不会true视实现通常不相等递归比较内容从这个表能看出标题里说的“更严格”核心就是两件事第一让NaN能和自己相等第二把0和-0区分开。再进一步就是让对象和数组做深度递归比较而不是只看引用。这也解释了为什么它比更严格认为0和-0相等这套 API 认为不相等只看对象引用这套 API 还会看对象内部字段。2. 更严格的相等性判断 API 到底怎么用2.1 先看一个统一的 API 形态在执行层面这类 API 通常接收两个参数返回一个布尔值。基本形态就长这样isStrictEqual(1, 1); // true isStrictEqual(NaN, NaN); // true isStrictEqual(0, -0); // false isStrictEqual(1, 1); // false isStrictEqual({ name: userA }, { name: userA }); // true isStrictEqual({ a: { b: NaN } }, { a: { b: NaN } }); // true第一行和第四行的行为和一致比较的是普通原始值类型不同直接返回 false。第二行开始就不一样了NaN与自身相等这是做不到的。第三行区分了正零和负零。第五行更关键两个内容相同的普通对象比较结果为 true不需要你手动写递归。这里强调一下不同环境里这套 API 的命名可能不同有的放在全局有的挂在某个工具模块下。你在实际项目里使用前先确认目标环境提供的是哪个名称或者自己封装一层。重点是它不是一个新语法糖而是一套完整的判定规则。它解决的事情是把下面这些规则一次性固定下来避免大家各自手写递归。2.2 API 背后的判定规则和边界我总结一下这类 API 常见的判定规则方便你理解它不是魔法。第一原始值按SameValue处理。所以NaN等于NaN0不等于-0。如果你用的实现采用SameValueZero那么0和-0会判为相等这个差异是最容易踩的坑。第二普通对象和数组会递归比较所有自有可枚举属性通常会先比较键的数量再逐个比较每个键的值。第三内建对象有专门分支Date 比较时间戳而不是引用RegExp 比较正则源码和 flags。第四原型不同通常判为不相等这和“不同 class 的实例不该相等”的直觉一致。第五循环引用要能被安全处理不能因为对象里有一个字段指回自身就无限递归。拿对象比较做例子实现细节经常藏在“键数量”这几个字里。我在实际排查中遇到过很多次两个对象一眼看过去字段一样但一个多了一个值为undefined的属性另一个没有这个属性。普通手写递归很容易把这两者当成相等因为a.missing b.undefinedValue可能都是undefined。严谨的 API 会先检查key是否同时存在于两侧而不是直接比较a[key]和b[key]这样就能区分“缺失属性”和“属性值为 undefined”。还有 Symbol 键。Object.keys不会枚举 Symbol 属性但一个对象完全可以有Symbol(id)属性。严格的 API 可能会通过Reflect.ownKeys把 Symbol 键也纳入比较范围避免两个“可枚举属性相同但 Symbol 属性不同”的对象被误判为相等。这些细节普通深比较函数根本顾不上。2.3 为什么不再需要和实际项目里引入这套 API 之后最直接的感受是少了一大批手写判断分支。以前遇到需要“内容相等”的场景我们可能会写这种代码function isCacheHit(cached, current) { if (Object.is(cached, current)) { return true; } if (typeof cached ! typeof current) { return false; } if (Array.isArray(cached) Array.isArray(current)) { if (cached.length ! current.length) { return false; } return cached.every((item, index) isCacheHit(item, current[index])); } if (cached current typeof cached object) { const keysA Object.keys(cached); const keysB Object.keys(current); if (keysA.length ! keysB.length) { return false; } return keysA.every((key) isCacheHit(cached[key], current[key])); } return false; }这还只是处理了普通对象和数组遇到 Date、RegExp、Map、Set、循环引用又得继续往外扩。换成严格相等性判断 API 后这个函数可以缩减成一行isStrictEqual(cached, current)。我不是说从此完全不能写。如果比较的是布尔开关、字符串枚举、数字 ID并且确定不涉及NaN和-0依然清晰高效。我的建议是项目里统一封装一个eq(value, other)工具内部优先调用严格相等 API老代码再逐步迁移。这样以后想替换实现、调整边界策略都只改一个地方。3. 从手写稳定版深比较到使用 API3.1 一个可复制的参考实现如果你所在环境暂时不提供这类 API或者你需要在老版本浏览器上运行可以自己写一个简化版实现。但我想先说清楚下面这段代码是“教学版”不是“生产版”目的是帮你理解递归判等、原型检查和循环引用处理真正用到生产环境前你还需要根据自己的数据场景补充很多分支。function deepIsEqual(a, b, seen new WeakMap()) { if (Object.is(a, b)) { return true; } if (typeof a ! typeof b) { return false; } if (a null || b null) { return false; } if (typeof a ! object) { return false; } if (a instanceof Date || b instanceof Date) { return a instanceof Date b instanceof Date a.getTime() b.getTime(); } if (a instanceof RegExp || b instanceof RegExp) { return a instanceof RegExp b instanceof RegExp a.source b.source String(a.flags) String(b.flags); } if (ArrayBuffer.isView(a) || ArrayBuffer.isView(b)) { if (!ArrayBuffer.isView(a) || !ArrayBuffer.isView(b)) { return false; } if (Object.getPrototypeOf(a) ! Object.getPrototypeOf(b)) { return false; } if (a.length ! b.length) { return false; } for (let i 0; i a.length; i) { if (a[i] ! b[i] !(Number.isNaN(a[i]) Number.isNaN(b[i]))) { return false; } } return true; } if (a instanceof Map || b instanceof Map) { if (!(a instanceof Map) || !(b instanceof Map) || a.size ! b.size) { return false; } for (const [key, value] of a) { let matched false; for (const [key2, value2] of b) { if (deepIsEqual(key, key2, seen) deepIsEqual(value, value2, seen)) { matched true; break; } } if (!matched) { return false; } } return true; } if (a instanceof Set || b instanceof Set) { if (!(a instanceof Set) || !(b instanceof Set) || a.size ! b.size) { return false; } for (const item of a) { let matched false; for (const item2 of b) { if (deepIsEqual(item, item2, seen)) { matched true; break; } } if (!matched) { return false; } } return true; } if (Object.getPrototypeOf(a) ! Object.getPrototypeOf(b)) { return false; } if (seen.has(a) seen.get(a) b) { return true; } seen.set(a, b); const keysA Object.keys(a); const keysB Object.keys(b); if (keysA.length ! keysB.length) { return false; } for (const key of keysA) { if (!Object.prototype.hasOwnProperty.call(b, key)) { return false; } if (!deepIsEqual(a[key], b[key], seen)) { return false; } } seen.delete(a); return true; }这段代码的关键点有几个。Object.is(a, b)在最前面处理了原始值、NaN、0和-0的情况。紧接着的typeof a ! typeof b其实已经隐含处理了“一个是对象一个是原始值”这类基础不匹配。Date 分支用getTime()比较因为 Date 对象没有自有可枚举属性直接遍历普通对象分支会得出“两个不同日期相等”的错误结论。RegExp 分支比较source和flags这两项能代表一个正则表达式的语义。TypedArray 分支按元素逐个比较同时允许NaN元素相等。原型检查在很大程度上决定了实现是“严格”还是“宽松”。如果两个对象的原型不同内容再一样也返回 false。比如一个对象来自Object.create(null)另一个对象来自普通对象字面量两者字段相同但底层原型不是一个东西许多业务场景不该把这两个对象当成同一个数据模型。确定是否需要这个判断取决于你的数据来源是否统一。循环引用处理包括两个动作把当前配对的(a, b)记录在WeakMap里以及在递归返回前删除。如果两个对象的循环结构不一致比如一个对象循环字段next指向自身另一个对象循环字段指向第三个对象那么在遍历路径上记录的内容不同最终会返回 false。这个逻辑比“见过就返回 true”严谨得多。不过这段实现依然是简化版因为真正的循环图比较还需要更多对冲不是一两百行能解决的。3.2 直接使用 API 的工程示例如果环境已经支持这类 API业务代码会干净得多。我以一个配置合并模块为例假设某系统需要判断旧配置和新配置是否发生了实质性变化import { isStrictEqual } from your-equality-utils; function shouldUpdateConfig(oldConfig, newConfig) { return !isStrictEqual(oldConfig, newConfig); }新配置可能来自用户编辑也可能来自服务端返回的 JSON。这里有一个非常容易忽略的点从JSON.parse得到的结构里本身不会出现NaN、undefined和-0因为 JSON 协议不支持这些值NaN会被转成null-0会被转成0。所以这套 API 对 JSON 数据依然有效但它不会帮你做类型归一化。你以为{ time: 2025-01-01 }和{ time: 2025-01-01T00:00:00Z }是同一个时间API 不会这么认为它只会老老实实比较字符串。所以在真实工程里比“怎么调用 API”更重要的经验是进入比较前先统一数据模型。把时间字段统一转成毫秒时间戳把枚举转成数字把缺省字段补上默认值再做相等判断。这样既能让 API 发挥最大价值也避免在比较逻辑里堆一堆例外判断。3.3 手写实现和官方 API 的差距手写深比较最容易出现的四个问题我这里单独列出来。第一是 getter 副作用。递归比较会访问对象的所有属性如果某些属性是通过 getter 动态计算的比较一次就会触发一次计算。要是 getter 里还有自增计数、打日志、发请求这类副作用整个比较过程就不是只读操作了很可能改变程序状态。规范的 API 实现同样会访问 getter这一点没有银弹所以只建议对纯数据对象使用深比较碰到带方法的类实例先考虑自定义equals方法或者先转成 DTO 再比较。第二是 Map 和 Set 的比较成本。手写实现里最简单的是两层循环匹配时间复杂度接近O(n^2)元素一多就容易卡。严格 API 可能会针对字符串、数字这类普通 key 做预排序或哈希但对象 key 仍然是一个难题。实际项目中如果 Map 的 key 是复杂对象我的做法是先把它转成可哈希的字符串结构或者干脆避免在 Map 里塞对象 key。第三是稀疏数组。new Array(3)和[undefined, undefined, undefined]在语义上不同前者是三个空位后者是三个显式undefined属性。Object.keys会把空位跳过导致一些手写实现把这两个数组误判为相等。严格的 API 会走更底层的键判断或者单独处理数组长度和元素存在性才能区分开这二者。第四是跨 realm 比较。iframe 或不同全局环境里同一个构造函数会在不同 realm 各有一份实现。两个内容一致的对象如果分别来自两个 iframe它们的原型对象不是同一个引用严格 API 判 false 是合理的但有些人会觉得意外。做跨窗口数据比较时要把数据先序列化成普通 JSON 结构再调用 API原型差异就不会干扰了。4. 实际项目里怎么选型4.1 什么时候可以继续用我不会建议你把代码里所有都替换掉。在比较两个原始值且你确定它们不会出现NaN和-0的时候是最高效、最直观的选择。比如一个布尔开关、一个状态枚举、一个自增数字 ID的光速判断没有问题。对象引用比较也有用武之地。判断点击事件中event.target是否等于某个 DOM 元素判断组件接收的新 props 对象是否就是旧 props 引用这类场景要的是“是不是同一个对象”不是“内容是否相等”甚至是唯一正确的选择。真正需要替换的是那种“我期望它们按内容相等却因为引用不同被判 false”的地方。我自己的习惯是给项目定一套比较规范原始值用NaN判断用Number.isNaN或严格 API需要判断对象内容时用严格 API只需要引用相同时显式写出来。规范写清楚之后团队成员就不必在每个文件里重复纠结。4.2 选型矩阵为了方便参考我把常见需求和建议方案整理成一个表格比较需求建议方案原因普通原始值比较最快语义直观判断NaN是否相等Object.is或严格相等 API无法处理区分0和-0Object.is或严格相等 API把二者视为相同Map/Set 键比较SameValueZero与容器内部语义一致两个对象内容一致严格相等 API递归处理嵌套结构只判断引用是否相同不需要深比较表单缺省字段比较先规范化再用严格 API避免缺失字段干扰这个表格可能和你平时想的不一样。很多人觉得“对象比较”就是深比较的代名词但实际上如果对象是不可变数据新旧版本共享大部分节点用引用比较是 O(1) 的如果直接用深比较性能会差很多。更好的方式是先比较版本号或修改时间版本号一样就跳过版本号变了再做深比较。4.3 注意性能和副作用严格相等 API 虽然方便但它是递归实现最坏情况下的时间复杂度和对象字段总量成正比也就是 O(n)其中 n 是参与比较的属性总数。这和的 O(1) 不在一个量级。在滚动列表更新、Web Worker 传输大量结构化数据这种高频场景里不要每次渲染都做全量深比较否则页面很快会有卡顿感。遇到这种情况我通常会引入“分层比较”策略。第一层比较轻量指纹比如计算数据的 hash 或版本号指纹相同时直接判定相等指纹不同再调用严格的深度比较定位具体差异。这就像先看包裹外包装有没有破损外包装完好就没必要拆开逐件点货。还要注意比较结果受到对象属性顺序的影响吗答案是不应该受影响因为严格 API 比较的是键集合而不是键的顺序。两个对象字面量声明属性的顺序不一样只要键名和值相同API 会判 true。这也是它比JSON.stringify方案优越的一个原因。5. 常见问题与排查技巧实录5.1 那些我踩过的坑第一个坑是用JSON.stringify做深比较。我一度为了快速判断配置是否变化写过JSON.stringify(a) JSON.stringify(b)。看起来能用直到某个版本的接口返回的字段顺序变了内容明明一样判断结果却变成 false。更隐蔽的是JSON.stringify会把undefined、函数、symbol 都忽略掉把NaN转成null把-0转成0。于是{ x: undefined }和{}会被比较成相等两个{ x: NaN }也被比较成同一字符串。这种写法从根上就错了严格 API 不会做序列化它直接遍历原始结构undefined和NaN都保留原始语义。第二个坑是循环引用导致栈溢出。手写深比较时如果对象里有一个parent字段指回根对象递归会无限深入直到抛出RangeError: Maximum call stack size exceeded。严格 API 会维护一个已访问对象的映射发现相同路径后返回避免无限递归。但你要注意循环引用相同只代表路径匹配不代表两个对象一定相等如果两侧的循环结构布局不同必须继续比较后续字段不能因为见过就提前返回 true。第三个坑是 Date、RegExp 被当成普通对象。手写递归如果只遍历自有可枚举属性Date 对象没有任何可枚举字段于是两个时间不同的 Date 对象会被误判为相等。RegExp 也类似两个source完全不同的正则表达式在普通深比较里可能都是空对象。严格 API 为它们设计了专门分支Date 比较时间戳RegExp 比较源码和 flags这才符合业务直觉。第四个坑是 Map 和 Set 的复杂度爆炸。朴素的 O(n^2) 匹配在几百个元素时就明显卡顿。更关键的是Map 内部的键比较规则是 SameValueZero和你用严格 API 深比较一个对象 key 的规则不一定一致。你用它比较两个只有 key 顺序不同的 Map可能会得到完全不同的匹配路径。实际工程里我很少对 Map 做全面深比较通常会先转成普通对象或者用稳定的序列化规则生成 key 后再做哈希然后比较哈希值性能问题会好很多。第五个坑是原型链上多出来的属性。普通深比较用Object.keys遍历天然忽略原型链上的方法这本来是对的。但两个对象原型不同时业务上是否应该相等并不总是清晰的。比如Object.create(null)和普通对象字面量内容相同但原型不同。如果数据都来自JSON.parse原型都是Object.prototype问题不大如果来自 class 实例严格 API 会检查原型避免不同类的实例被误判为相等。但在跨 realm 场景下同一个 class 被两个全局环境各加载一次它们的原型不是同一个引用内容再像也会判 false跨窗口比较时要特别注意。5.2 问题速查表我把高频问题整理成一个速查表方便你排查时直接查现象可能原因处理方式缓存命中率一直为 0用比较含NaN的值改用Object.is或严格相等 API0和-0被当成相等使用判断符号零敏感值改用 SameValue 语义的 API对象内容相同但比较结果为 false还在用引用比较使用严格相等 API深比较时栈溢出对象存在循环引用使用能处理循环引用的 API两个 Date 内容不同却被判相等手写递归把 Date 当普通对象单独比较getTime()对象键顺序不同导致误判使用JSON.stringify做比较不要序列化直接递归比较比较过程触发了副作用getter 被递归访问只比较纯数据或先转 DTO不同 iframe 对象内容相同但不等原型跨 realm 不一致先序列化再比较排查的时候最好的方法是先写一个最小复现把两个要比较的值分别打印出来再调用 API 验证。不要带一堆业务上下文去猜往往把问题缩小到“两个变量的值分别是什么”这一步答案自己就出来了。5.3 自定义相等语义的正确姿势一个很容易被忽略的点是大多数通用相等 API 只能覆盖常见的内建对象和普通数据遇到自定义类它只能猜测你的相等语义。比如一个Person类业务上规定id相同就算同一个人其他字段是否相同没关系。通用 API 不会知道这个规则它会把整棵数据树递归比较完最后可能因为address多了一个空格返回 false。遇到这种情况我更建议在自定义类上实现显式的equals方法让使用者调用a.equals(b)。同时保留一个toJSON方法把内部数据归一化成纯对象方便严格 API 在跨系统边界时使用。这比要求所有调用方都依赖通用深比较要可靠得多。当然自定义equals也有自己的要求先比较引用再比较关键字段最后处理类型不一致的情况。还要保证相等关系满足对称性否则很容易写出“自以为相等但对方不觉得相等”的代码。把这些规则整理成一个小文档放进项目里运维成本会低很多。6. 进一步理解为什么“更严格”不等于“绝对正确”6.1 API 也是语义裁剪的结果我必须要说一点容易被误解的事严格相等性判断 API 虽然比严格但并不意味着它天然适合所有业务语义。它只是把一组特定的规则固化下来让比较行为可预期。同样的两个值在不同规则下可能得到不同结果。举个例子你说“两个对象的NaN字段应该相等”这是一个语义选择。你说“0和-0应该相等”这是另一个语义选择。这两者无法同时满足因为一个是 SameValue一个是 SameValueZero。所以你在选 API 时并不是选一个“绝对正确”的而是选一个“更贴近当前业务约定”的。这也解释了为什么同样一套深比较逻辑有的方案坚持区分0和-0有的方案却不区分。我遇到过一个实际案例某个项目用 Map 做推荐结果的缓存key 是搜索参数对象里面既有数字也有布尔值。由于 Map 的键判断走 SameValueZero搜索参数里0和-0被认为是同一个键这符合预期。但缓存结果判断时又想用更严格的 SameValue结果同一次搜索0和-0会命中两个不同的缓存。后来统一成 SameValueZero问题才消失。可见在不同环节用不同相等语义完全可能导致“同一份数据前后判断结果不一致”。6.2 给项目封装统一比较入口既然相等语义这么容易混我的建议是在项目里做一个统一封装而不是每个人直接调用底层 API。封装的时候要明确几个问题是否区分0和-0要不要检查原型是否处理循环引用Date 要不要比较时间戳。把这些参数变成配置项让调用方显式表达意图。封装之后引用比较、普通原始值比较、深比较都走同一个入口但要保证函数命名能表达语义。比如function eq(a, b) { return isStrictEqual(a, b); } function refEq(a, b) { return a b; } function sameValueZero(a, b) { return a b || (a ! a b ! b); }假如我遇到一个NaN比较需求我会直接调eq(NaN, NaN)而不是去记NaN NaN的规则。遇到只需要引用比较的地方我显式写refEq让后续维护的人不会误以为是深比较。这种命名和封装比直接用运算符更有利于代码审查。6.3 后续扩展自定义比较器和数据归一化如果项目的数据结构特别复杂统一封装会慢慢长成一个小型比较框架。比如需要忽略某些字段、需要在比较前对字段做清洗。我更建议把“比较”和“归一化”分开写function normalizeForComparison(value) { if (value instanceof Date) { return value.getTime(); } if (value typeof value object) { return Object.fromEntries( Object.entries(value).map(([key, item]) [key, normalizeForComparison(item)]) ); } return value; } function eqNormalized(a, b) { return isStrictEqual(normalizeForComparison(a), normalizeForComparison(b)); }这个思路是把所有数据先统一成普通对象和基本类型再交给严格 API 判断。Internet 上跨系统传输的数据、从 JSON 解析的数据、来自不同 iframe 的数据经过归一化后都能比较原型差异被抹平了。不过这只是一个示范如果你有更复杂的自定义比较逻辑完全可以在归一化阶段做字段裁剪而不是在比较阶段增加特殊情况。我个人近几年写相等性判断代码时已经很少直接甩去比可能包含NaN的可疑数据。把标题这句话落到工程里它其实是一句提醒相等性判断不该靠运算符硬撑而应该靠明确语义和标准化 API。只要你先把eq工具封装好内部用严格相等 API外部暴露成统一方法后续升级实现、排查边界都会轻松很多。最后分享一个小技巧任何相等性 API 都不是银弹用之前先问自己三个问题。两个值里可能含有NaN或-0吗你关心对象引用还是对象内容类型不一致时你想得到 false还是希望做一次转换这三个问题想清楚了该用哪个 API基本不用纠结。