一文搞懂eq是什么：Vue源码深度拆解

一文搞懂eq是什么：Vue源码深度拆解 复制来的代码跑不通，是不是经常不知道从哪下手调？别慌，今天咱们不聊虚的，直接钻进 Vue 的源码里，一文搞懂 eq 到底是个啥，怎么在响应式系统里悄悄干活。 入口定位：谁在调用 eq 很多人搜 eq，脑子里蹦出来的可能是 Python 的 ==，或者 Java 的 equals。但在 Vue 3 的依赖收集与更新机制里，eq 是一个极其关键却容易被忽略的函数。它藏在 @vue/runtime-core 的响应式核心逻辑中，专门负责判断两个值是否“相等”。 为什么需要它？因为在 Vue 的 effect 执行过程中，如果依赖的值没变，我们就不该触发视图更新。这里的“变”，不是简单的引用比较，而是需要一种更智能的相等性判断。eq 就是那个裁判。 在 packages/reactivity/src/effect.ts 中，当我们追踪依赖时，track 函数会记录当前 effect 依赖了哪个 key。当值发生变化时，trigger 函数会检查新旧值是否相同，如果相同，就不通知依赖更新。这个检查，就调用了 eq。 你可以把它理解为 Vue 内部的“值对比引擎”。它不处理复杂的对象深度比较，而是针对基本类型和简单引用类型做高效判断。这种设计避免了不必要的递归和性能损耗，是 Vue 追求极致性能的一个缩影。 核心片段：eq 的源码实现 下面这段代码来自 Vue 3 的 packages/reactivity/src/baseHandlers.ts，是 eq 函数的核心实现。注意，这里不是简单的 ===，而是结合了 Object.is 和特殊情况的处理。 // packages/reactivity/src/baseHandlers.ts // 判断两个值是否相等，用于依赖收集时跳过未变化的值 const eq = (a: any, b: any): boolean = {// 1. 快速路径：如果两个值都是 NaN，返回 true// 因为 NaN !== NaN，但业务上我们希望 NaN 和 NaN 视为相等if (a === b) {// 2. 处理 NaN 的特殊情况// Object.is(NaN, NaN) 返回 true，而 === 返回 falsereturn a !== 0 || 1 / a === 1 / b}// 3. 其他情况：使用 Object.is 进行严格相等判断// Object.is 比 === 更严格，能区分 +0 和 -0return Object.is(a, b) }逐行拆解：第 1 行：函数定义，接收两个任意类型的参数，返回布尔值。这是最基础的相等性判断入口。 第 2-5 行：快速路径优化。如果 a === b 为真，进入内部判断。这里有个经典技巧：1 / a === 1 / b。当 a 和 b 都是 0 时，1/0 是 Infinity，相等；当一个是 +0，一个是 -0 时，1/+0 是 Infinity，1/-0 是 -Infinity，不相等。这完美解决了 +0 === -0 但业务上可能希望区分的问题。 第 6-7 行：如果 a === b 为假，直接走 Object.is。Object.is 是 ECMAScript 6 引入的严格相等比较函数，它和 === 的区别在于：Object.is(+0, -0) 返回 false，而 +0 === -0 返回 true；Object.is(NaN, NaN) 返回 true，而 NaN === NaN 返回 false。这个实现看似简单，实则处处是坑。比如，如果你用 === 判断 NaN，永远返回 false，导致 Vue 可能错误地认为值变了，触发不必要的更新。eq 的存在，就是为了让这个判断更准确、更高效。 在 MDN Web Docs 中，Object.is 的文档明确指出，它提供了比 === 更精确的相等性判断，特别是对于 NaN 和 ±0 的处理。Vue 在这里选择 Object.is 作为兜底，正是遵循了规范的最佳实践。 设计思想：为什么不用 === 你可能会问：为什么不直接用 ===？这涉及到 Vue 响应式系统的设计哲学。 第一，性能优先。 eq 的第一行就是 a === b 快速路径。对于绝大多数基本类型（数字、字符串、布尔值），=== 是 O(1) 的，速度极快。只有当 === 返回 false 时，才进入更复杂的判断。这种“快速失败”策略，避免了每次都调用 Object.is 的开销。 第二，语义准确。 在响应式系统中，“相等”意味着“值没有变化，不需要更新视图”。如果 NaN 被错误地视为“变化”，会导致组件频繁重渲染，影响性能。eq 通过处理 NaN 和 ±0，确保了语义的准确性。 第三，可扩展性。 虽然当前 eq 只处理基本类型，但它的接口设计是通用的。如果未来需要支持对象浅比较，只需修改函数内部逻辑，不影响外部调用。这种“小接口，大实现”的设计，是源码级别的优雅。 对比 Python 的 ==，它会对对象调用 __eq__ 方法，可能触发复杂的递归比较。Vue 的 eq 则刻意保持轻量，只处理响应式系统关心的基本类型和简单引用。这种克制，正是高性能框架的体现。 手写简化版：自己实现 eq 为了加深理解，我们手写一个简化版的 eq，模拟 Vue 的核心逻辑。 // 简化版 eq，模拟 Vue 3 的相等性判断逻辑 function simpleEq(a: any, b: any): boolean {// 1. 快速路径：=== 判断if (a === b) {// 2. 处理 0 的特殊情况// 如果 a 和 b 都是 0，通过倒数判断是否同号return a !== 0 || 1 / a === 1 / b}// 3. 兜底：Object.is 严格比较return Object.is(a, b) }// 测试用例 console.log(simpleEq(1, 1)) // true console.log(simpleEq(NaN, NaN)) // true console.log(simpleEq(+0, -0)) // false console.log(simpleEq(+0, +0)) // true console.log(simpleEq(a, a)) // true console.log(simpleEq({}, {})) // false (引用不等)运行结果符合预期。注意，simpleEq({}, {}) 返回 false，因为两个对象引用不同。Vue 的 eq 也不做深度比较，这是为了性能。如果需要深度比较，应该使用 lodash.isEqual 等工具，而不是在响应式核心中做。 这个简化版的核心思想是：能用 === 解决的，绝不用 Object.is；=== 搞不定的，才用 Object.is 兜底。 这种分层处理，是源码设计中常见的“快速路径 + 慢速路径”模式。 在转岗到前端领域时，理解这种底层设计思维非常重要。很多面试会问“为什么 Vue 不用 === 判断依赖变化”，如果你能说出 NaN 和 ±0 的处理，以及性能考虑，面试官会眼前一亮。 应用场景：eq 在依赖收集中的角色 eq 不仅是一个独立的函数，它是 Vue 响应式系统中依赖收集与触发的关键环节。 在 trigger 函数中，当 reactive 对象的某个 key 的值发生变化时，Vue 会找到所有依赖该 key 的 effect，然后检查新旧值是否相等。如果相等，就跳过该 effect，不触发更新。 // 简化版 trigger 逻辑 function trigger(target, key, oldValue, newValue) {const deps = target.__v_deps?.get(key)if (deps) {for (const effect of deps) {// 关键：使用 eq 判断值是否真的变化if (!eq(oldValue, newValue)) {effect.run() // 只有值变化，才执行副作用}}} }这个机制确保了：只有当值真正变化时，才触发视图更新。如果值没变，即使你手动调用了 set，也不会重渲染。这就是为什么 Vue 3 比 Vue 2 性能更好的原因之一。 在实际项目中，如果你发现组件频繁重渲染，可以检查是否是因为 eq 判断失效。比如，如果你返回一个新的数组对象，即使内容相同，eq 也会返回 false，导致更新。这时候，你应该返回引用相同的数组，或者使用 shallowRef 来避免深度追踪。 理解 eq 的工作原理，能帮你更好地调试响应式问题。当你的代码“跑不通”时，不是代码错了，而是你对底层机制理解不够。深入源码，才能写出高性能、可维护的代码。 你公司项目里是怎么处理的？欢迎评论分享你的经验。