先看清它的限制

中间那步 optimize 是 Vue2 编译期最有价值的一步。 它给每个 AST 节点打上 static 标记，标记过的节点在 patch 时会被整棵跳过——不对比、不更新，因为它的内容不可能变。 这就是"编译期优化"，也是 Vue3 把这条路走到极致（静态提升、Patch Flag）的起点。

• 运行时编译 vs 构建时编译：带 template 选项的写法需要编译器（体积大）；.vue 文件在构建时就编译好了，运行时只需要 render 函数，所以生产包更小。
• render 函数里的 with(this)：让模板里的 msg 能直接找到 this.msg。严格模式下不能用 with，所以编译产物不是严格模式代码。
• _c / _v / _s 分别是 createElement、createTextVNode、toString 的简写，为了减小产物体积。

这套机制的三个盲区，全部来自 defineProperty 只能"预先给已知的 key 装钩子"这个本质：

• 为什么是递归全量遍历：初始化时就要把所有层级都装上钩子。深层大对象 → 启动时慢，这是 Vue2 的性能瓶颈之一。
• Dep.target 是个全局变量：它是"当前正在执行的那个 watcher"，Watcher 求值前把自己设成 target，求值后复原。这是"依赖收集"的关键技巧。
• 一个 watcher 可能对应多个 dep：渲染 watcher 用到了 msg 和 list，就同时被两边的 dep 收集。

• 为什么已存在的 key 可以直接赋值：因为它早就被 defineReactive 处理过了，setter 自己会 notify。
• 为什么需要 __ob__：这是 Vue 在响应式对象上挂的一个隐藏属性（不可枚举），指向 Observer 实例，用来判断"这个对象是不是响应式的"。
• 根数据对象上直接赋值也不行：this.$data.newKey = 1 同样不响应，得用 this.$set(this.$data, ...)。

至于"为什么不给索引装钩子"，答案是两个：一是数组可能上万项，全量 defineProperty 代价太高；二是 length 变化 （arr.length = 0）根本没法用 defineProperty 有效拦截。 权衡之后，Vue 选择了"拦截操作方法"这条性价比更高的路。

• __proto__ 的兼容性问题：IE10 及以下不支持改 __proto__，Vue 会降级成"直接在数组实例上挂这 7 个方法"，只处理被调用过的数组。
• observeArray：push 进去的新对象也要被 observe，否则新加的元素改起来不响应。
• 副作用：这些方法的 enumerable 被设成 false，所以 for...in 不会多出东西，但 console.log(arr) 展开时可能看不到它们。

根实例 new Vue({ data: {...} }) 确实可以写成对象， 因为全局只有一个实例，不怕共享。但只要是被复用的组件，就必须是函数。

• 本质是 JS 的对象引用：{ count: 0 } 字面量在模块加载时只创建一次，之后所有实例都指向它。
• 这也是为什么 return 里面要新建对象：如果 return someSharedObject，问题一样存在。
• Vue3 用 <script setup> 时不存在这个问题：setup 本身就是函数，每次实例化都执行一遍。

注意最后那段：依赖变化时，computed 不会立刻重算，只是把 dirty 设为 true。如果不读它，就永远不算——这就是"惰性求值"。

• computed 也能写 setter：{ get() {...}, set(v) {...} }，用于 v-model 绑定一个派生值。
• computed 里不能有副作用：它是纯计算，不要在里面发请求或改 state。
• 缓存失效条件：只有它响应式依赖变化时才置 dirty。非响应式变量变了它不知道。

• deep: true 有成本：它会递归遍历对象，给每一层都收集依赖。数据量大时（比如几千条列表）要慎用，能监听具体路径就别开 deep。
• immediate: true 时 oldVal 是 undefined：因为这是"第一次"，没有上一个值。
• 数组的 watch：监听数组时不需要 deep（Vue 会处理），但监听"数组里对象的属性变化"还是需要。
• watch 里能写异步：await 请求、$nextTick、DOM 操作都可以；computed 里不行。

• nextTick 底层用什么：优先 Promise.then（微任务），降级 MutationObserver → setImmediate → setTimeout。微任务的时机是"当前宏任务结束、浏览器渲染之前"，正好卡在用户看到画面之前。
• 为什么要按 id 排序：父组件的 watcher id 一定小于子组件（先创建），排序后保证"父先更新"，避免子组件重复渲染。
• watcher.run() 里有值比较：求值后如果新值和旧值相同，会跳过 patch。这是第二层优化。
• $nextTick 拿到的回调在 DOM 更新之后执行，所以能安全读取 $el 的新尺寸。

注意 sameVnode 这个判断——它只有两个条件。 所以 key 一变，Vue 就认为"这不是原来那个节点了"，直接重建。 key 的第一个作用就在这里。

• VNode 不是 DOM：它没有 DOM 的任何能力（不能 appendChild、没有 offsetWidth），只是一个 plain object。
• elm 是双向绑定的锚点：vnode 记住它的真实 DOM，下次 patch 就能直接拿到。
• 首次 patch 传的 oldVnode 是 $el：也就是真实 DOM，所以要先 emptyNodeAt 转一下。

举个最容易理解的例子：把列表整体反转。
旧 [a, b, c] → 新 [c, b, a]。 第一轮 ①③ 都不中，但 ③"旧头 a vs 新尾 a" 命中 → a 直接挪到末尾； 第二轮 ③ 又命中 b；第三轮 ③ 命中 c。全程三次移动，零次新建。

• 时间复杂度 O(n)：前提是"只做同层比较 + 用 key 找对应"。没有 key 也建不了索引表，就退化成逐个查找，O(n²)。
• oldCh[idxInOld] = undefined：处理过的位置置空，后面遇到 undefined 就跳过（源码里有专门的 isUndef 分支）。
• insertBefore 是唯一真正动 DOM 的操作：所有"移动"都靠它，没匹配上的才 createElm 新建。

过程是这样的：删掉第一项后，list 从 [A, B] 变成 [B]。 新的 key 是 0，旧的 key 0 还存在 → sameVnode 返回 true → 复用第一个 <li> 节点，只把 <span> 的文字从 A 改成 B。 那个输入框 DOM 根本没被替换，用户敲的字就留在原地。

• 用 index 也不会报错：这是最坑的地方——功能看起来正常，只有涉及"节点内部有状态"时才暴露。
• 什么时候可以接受：列表只用于渲染、绝不增删排序，且项内没有任何有状态的东西。这种场景很少。
• 没有唯一 id 时：可以用"业务上稳定的字段组合"，或者给数据加一个生成 id 的步骤。都不要用 index。
• key 不要用随机数：Math.random() 每次渲染都变，会导致整列表重建，性能极差。

记忆方法：创建和挂载是"子先完成"，更新和销毁是"父先开始"。 因为父组件要先把自己的模板解析出来，才知道子组件存在（所以 beforeMount 在子之前）； 但子组件挂载完成后父组件才能说自己整体完成（所以 mounted 在子之后）。

• 发请求放 created 还是 mounted？ 都可以。created 更早，SSR 也能执行；mounted 能拿到 DOM。不要放在 beforeMount（此时拿不到 DOM，而且还会被服务端渲染跳过）。
• 操作 DOM 必须 mounted 之后，而且如果要读"更新后"的尺寸，还得配合 $nextTick。
• 清理逻辑写 beforeDestroy：清定时器、解绑 EventBus、移除 window 监听。写在 destroyed 里也能跑，但那时组件已经开始拆，时机偏晚。
• <keep-alive> 多两个钩子：activated / deactivated，缓存的组件切回来时触发，不会重新走 created。

真正容易答错的是下面这个：

• 为什么 Vue3 反过来了：Vue2 的顺序导致每次循环都要跑一遍条件，白耗性能；Vue3 改成 v-if 先判断，逻辑上更合理，同时直接编译报错逼你改写法。
• v-if 写在 <template> 上可以一次控制多个元素，不产生额外 DOM。
• v-if 会让组件重新走一遍完整生命周期：所以如果子组件里有请求，切换时就会重新请求。想缓存用 <keep-alive>。

• $refs：父直接调子的方法/拿子的数据。属于"打破封装"的做法，适合表单校验这类场景，别到处用。
• .sync 修饰符：<Child :visible.sync="show" /> 会被展开成 :visible + @update:visible，是"多个 v-model"的 Vue2 方案。Vue3 里被 v-model:xxx 取代。
• $parent / $children：耦合太强、顺序不稳定，基本只在写高阶组件库时用。
• Vuex：中大型项目的标准答案。单向数据流：组件 dispatch action → action commit mutation → mutation 改 state → state 变化触发视图更新。

这四块代码在文件里被 data、computed、 watch、methods、mounted 隔开几百行。当你读到一个 this.loading，得往上翻很久才知道它从哪来。 功能越复杂，这个文件越难读——这才是真正的痛点。

• Vue2 里也能部分模拟：可以用 Vue.observable + 工厂函数做一点，但没有 ref/computed 这样好用的原语，写起来很别扭。
• mixin 的合并规则：生命周期钩子会被合并成一个数组（mixin 的先执行），data 和 methods 后覆盖先。这个规则容易记错。
• 不是"mixins 不能用"：全局混入做埋点、权限这类横切关注点仍然合理。问题出在"用 mixin 做主业务的逻辑复用"。

考前扫一遍。卡住的回去看对应那节。