每一项改动，都是在还债

为什么一定要用 Reflect？ 三个原因，最后一个最容易被忽略：

• receiver 要传下去：Reflect.get(target, key, receiver) 里第三个参数让 getter 里的 this 指向代理对象而不是原始对象，否则原型链上的 getter 会拿到错误上下文。
• 返回值语义统一：Reflect.set 返回布尔值，而 target[key] = v 永远是 undefined。代理的 set 必须返回布尔值，否则严格模式下会抛错。
• 失败时不静默：操作不成功会返回 false 而不是无声失败，方便上层判断。

• "惰性"不等于"不响应"：只是把代理的时机推迟到访问时。访问之后照样是完整响应式的。
• WeakMap 是必须的：如果用 Map，原对象已经没人用了，proxy 还挂在 Map 里，就内存泄漏了。
• 这也是 console.log(state) 看起来奇怪的原因：打印出来是一个 Proxy，DevTools 里要点开才能看到 target。

• ref 可以整体替换：count.value = 100 没问题。reactive 对象不能 state = {}，那样会丢掉响应性（详见下一节）。
• ref 解构不丢响应性：const { value } = count 这种写法本身没意义，但 ref 作为函数参数传递时不会断链。
• 返回值不同：ref 是 RefImpl 实例，reactive 是原对象的 Proxy。
• 项目里的实际选择：多数团队统一用 ref，因为可以避免"忘记能不能解构""能不能整体替换"这类心智负担；只有明确要一组关联数据时才用 reactive。

所以 toRefs 干的不是"深拷贝一份"，而是 给你一个通往原属性的管道。读它 = 读原对象，写它 = 写原对象， 但经过了 ref 的访问器，所以响应性还在。

• 这就是 composable 返回对象时要用 toRefs 的原因：调用方一解构，响应性就全断了。
• storeToRefs 是 Pinia 里的同类工具，专门用来从 store 解构出响应式引用。
• ref 不怕解构：因为它本身就是对象，解构出来的还是那个 ref 对象，读取仍然走 .value。

• 对比 mixins 的三个改进：名字可见（return 了什么就是什么）、来源可见（从哪个函数来的）、依赖可见（函数参数就是依赖）。
• 类型推导友好：普通函数返回值能被 TS 准确推断，mixin 的 this 扩展很难推导。
• 不是必须用：小页面用 Options API 反而更短。Vue3 两种写法可以混用，<script setup> 里也能用 defineOptions 配 options。
• 逻辑组合：composable 之间可以互相调用嵌套，像函数一样组合，mixins 做不到这么自然。

• 改名的两个：beforeDestroy → onBeforeUnmount、destroyed → onUnmounted。语义更准确——组件是被卸载，不是被"销毁"。
• <keep-alive> 的两个：onActivated / onDeactivated，用法不变。
• 新增调试钩子：onRenderTracked / onRenderTriggered，开发时能看到"这次渲染是哪个依赖触发的"。
• setup 不能是 async：async 会让返回值变成 Promise，模板拿不到。要异步就用 <Suspense> 配合或者在里面发请求。

• flush 的三个值：'pre'（默认，组件更新前）、'post'（更新后，可以读新 DOM）、'sync'（同步，慎用）。
• 监听 reactive 对象本身会自动 deep：watch(state, cb) 隐含深度监听，开销大。尽量监听具体属性。
• watchEffect 会追踪所有读到的响应式数据：哪怕只是在里面打了个 console.log，也算依赖。
• computed 不能有副作用：不要在 computed 里发请求或改别的 ref，它只负责算。

• PatchFlag 是负数表示"不用比"，正数表示"要比但只比这些"。
• 事件处理函数也会被缓存：onClick 编译成缓存的引用，避免每次渲染生成新函数导致子组件更新。
• 静态节点字符串化：一大段纯静态 HTML 会被编译成一个字符串，用 innerHTML 一次性设置，省去逐节点创建。
• 这些优化只对模板生效：手写 render 函数或用 JSX 时拿不到，会标 BAIL 退回全量 diff。

原因很直接：Block 的前提是"子节点的结构稳定"，这样拍平的数组顺序才不会错乱。 v-if 会整段出现或消失，v-for 的数量会变， 结构不稳定 → 所以它们内部要开新 Block，父 Block 只把"这个 Block 本身"记进数组。

• Block 用 openBlock() / createBlock() 包裹，编译产物里能看到。
• 收益随树规模放大：一棵 1000 个节点的树，只有 10 个是动态的 → 从遍历 1000 降到遍历 10。
• 这是 Vue3 相比 Vue2 最大的运行时性能提升，比 Proxy 那部分影响大得多（Proxy 主要改善的是初始化）。

• 时间复杂度 O(n log n)：二分查找那一步是关键；朴素的 DP 是 O(n²)。
• 注意 LIS 求的是"下标序列"，不是值序列——返回的下标用来决定"哪些旧节点不用移动"。
• 只有中间乱序部分才走 LIS：纯头插、纯尾插在阶段①②就被处理掉了，根本不会进到这里。
• 没有 key 时走 unkeyed 分支：按位置一一对应 patch，不建映射也不求 LIS。

代价是：多根组件无法通过 $attrs 自动透传属性， 因为 Vue 不知道该把 class 加到哪个根上，会给出警告。 需要手动指定：<Header v-bind="$attrs" />。

解决的是层叠上下文问题：弹窗如果写在深层嵌套的容器里， 父级的 overflow: hidden、transform、 z-index 都会把它裁掉或压住。Teleport 让 DOM 位置和组件层级解耦， 但事件冒泡、props、provide/inject 仍然按组件树走。

• Suspense 依赖组件的 async setup：setup 返回 Promise 时，Suspense 会等它 resolve 再渲染 default 内容。
• Teleport 支持 disabled：<Teleport to="body" :disabled="true"> 可以临时取消传送。
• Suspense 目前仍标记为实验性，API 在后续版本有调整，面试说到这点会显得你关注过细节。

• 为什么改 value → modelValue：value 这个 prop 名太容易和原生属性冲突（比如 input 的 value），改成专用名字更清晰。
• 自定义修饰符：Vue3 支持 v-model.trim 这类，子组件能拿到 modelModifiers 自己处理。
• 原生元素上的 v-model：Vue3 里 v-model 会自动根据元素类型选 prop 和事件（text 用 value/input，checkbox 用 checked/change）。

• Tree-shaking 的前提是 ESM：CommonJS 是运行时 require，静态分析不出来，摇不掉。Vue3 只发 ESM 版本。
• 副作用标记：库要在 package.json 里声明 sideEffects: false，否则打包工具不敢删。
• 模板编译可以放到构建期：.vue 文件在构建时编译成 render 函数，运行时就不需要 compiler 了。这也是为什么"运行时版"比"完整版"小很多。

• 第三方类实例被代理会出问题：Proxy 会拦截所有属性访问，某些库内部用 instanceof 或私有字段，被包一层之后行为就变了。
• markRaw 之后再 reactive，返回的还是原对象，不会有响应性。
• 大列表的常见优化：shallowRef 存列表，整批替换时触发一次更新，而不是逐项追踪几万个属性。

• 组件名怎么来：默认取文件名。要改就用 defineOptions({ name: 'Xxx' })，或者用两个 script 块。
• defineProps 不能解构（Vue 3.5 之前）：解构会丢响应性。要解构用 toRefs 或者 Vue 3.5+ 的响应式 props 解构。
• 顶层 await 可用：因为编译后 setup 会带 async，配合 <Suspense> 用。
• defineExpose：默认组件是"关闭"的，父组件通过 ref 拿不到内部东西，要显式暴露。

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