框架原理是前端面试里最能拉开差距的一块。背 API 谁都会，但”为什么 React 要引入 Fiber”、”Vue 的响应式为什么要用 WeakMap”、”虚拟 DOM 一定更快吗”这类问题，考察的是你能不能从设计约束反推出技术选型。

本文按虚拟 DOM → Diff → 响应式 → 调度 → 编译期优化五层组织，每层给出高频问题、标准答案要点，以及面试官真正想听到的那句话。版本坐标截至 2026 年 9 月：React 19.2.8、Vue 3.5.42（3.6.0-rc.7 在 RC）、Svelte 5.57.0、Solid 1.9.15。

一、虚拟 DOM：先把它请下神坛

Q1：虚拟 DOM 一定比直接操作 DOM 快吗？

不一定，而且这个说法本身就是错的。虚拟 DOM 的价值不是”更快”，而是把”什么变了”这件事从人脑转移到运行时，从而让你能用声明式的方式写 UI，同时保证一个可接受的性能下限。

精确的对比应该是：

• 首次渲染：虚拟 DOM 一定更慢——它多了一步构建 VNode 树和 render 的开销。
• 小范围精准更新：手写 el.textContent = x 一定更快，没有 diff 成本。
• 复杂视图的中大范围更新：虚拟 DOM 通常更快，因为它能批量计算出最小变更集，避免大量无谓的读写交错导致的重排。

面试高分答法：把”快不快”改成”在什么约束下换取了什么“——牺牲首次渲染性能和一点内存，换取声明式写法 + 可预测的性能下限 + 跨平台渲染能力（同一棵 VNode 树可以渲染到 DOM、Canvas、Native）。

Q2：为什么需要 key？用 index 当 key 会出什么问题？

key 是 diff 算法用来判断”新旧两个节点是不是同一个东西”的身份证。没有 key 时，框架只能按位置一一对应（就地复用），这在某些场景下会错误地复用了带有内部状态的节点。

// 反例：用 index 当 key
// 列表 [A, B, C]，删除 A 后变成 [B, C]
// index 复用后：原位置0 的 A 节点被复用成 B，组件内部 state 错位
{list.map((item, i) => <Row key={i} data={item} />)}

// 正例：用稳定业务 ID
{list.map(item => <Row key={item.id} data={item} />)}

典型翻车场景：列表项里有输入框、勾选状态、动画状态。删除第一项后，第二项的输入框内容会”跑”到第一项上。如果列表只是纯展示、无内部状态、无顺序变更，用 index 不会出问题——但这是个不该赌的假设。

二、Diff 算法：从 O(n³) 到 O(n) 的那一步

Q3：为什么树的最小编辑距离是 O(n³)，而框架能做到 O(n)？

因为框架放弃了”最优解”，只求”在真实场景下足够好的解”。它引入了三个启发式约束：

1. 只做同层比较，不做跨层级的节点移动。一旦发现节点跑到了别的层级，直接删掉重建。
2. 同层比较时按 key 匹配，通过哈希表把”找对应节点”从 O(n²) 降到 O(n)。
3. 类型不同直接整棵替换，不再往下比。<div> 变成 <span>，整棵子树重建。

这三条把问题从”通用树编辑距离”降到了”同层序列的匹配”，复杂度随之降为线性。

Q4：React 的 Fiber 到底解决了什么问题？

在 Fiber 之前（React 15 的 Stack Reconciler），递归遍历组件树是不可中断的——一次更新从根一路递归到叶子，中间不能停。组件树深了（比如几千个节点），这一次递归可能占住主线程几十到几百毫秒，期间用户输入、动画全部卡住。

Fiber 的核心改动是把递归改写成链表上的循环：

// Fiber 节点之间用三个指针连起来，形成可遍历、可中断的链表
fiberNode.child     // 第一个子节点
fiberNode.sibling   // 下一个兄弟节点
fiberNode.return    // 父节点

// 于是 workLoop 可以随时停下来
function workLoop(deadline) {
  while (nextUnitOfWork && deadline.timeRemaining() > 1) {
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork)
  }
  // 时间片用完了，把控制权还给浏览器，下一帧继续
  requestIdleCallback(workLoop)
}

这里要区分两个概念，很多人答混：

• Fiber 架构：数据结构 + 可中断的遍历机制（React 16 引入）。
• Concurrent 并发特性：基于 Fiber 的可中断能力，实现的优先级调度（React 18 引入）。useTransition、Suspense、自动批处理都建立在这上面。

Q5：useTransition 和防抖节流有什么区别？

这是 2026 年很常见的追问，两者解决的其实是不同层面的问题：

关键判断句：防抖是”少做几次”，useTransition 是”做是可以做，但别挡着用户”。前者减少了工作量，后者改变了工作安排的顺序。

三、响应式：两大阵营的根本分歧

Q6：Vue 3 的响应式是怎么实现的？为什么用 WeakMap？

核心是 Proxy 拦截 + 依赖收集。三层数据结构要能画出来：

// targetMap: WeakMap<object, Map<key, Set<effect>>>
const targetMap = new WeakMap()

function track(target, key) {
  if (!activeEffect) return
  let depsMap = targetMap.get(target)
  if (!depsMap) targetMap.set(target, depsMap = new Map())
  let dep = depsMap.get(key)
  if (!dep) depsMap.set(key, dep = new Set())
  dep.add(activeEffect)      // 收集依赖
}

function trigger(target, key) {
  const dep = targetMap.get(target)?.get(key)
  dep?.forEach(effect => effect())   // 触发更新
}

为什么最外层用 WeakMap？因为键是对象引用。WeakMap 持有弱引用，当响应式对象被销毁、没有任何其他引用时，垃圾回收可以正常回收它，对应的依赖集合也会自动消失。用 Map 会造成内存泄漏——对象已经不用了，但因为被 Map 的键强引用着，永远无法回收。

顺带一提，Vue 3.6 把内部响应式实现换成了 alien-signals，采用基于版本号的双向链表而非 Set 来组织依赖，内存占用和更新传播开销进一步下降。这是对外的实现替换，ref/reactive 的 API 行为保持一致。

Q7：React 为什么不做”自动依赖收集”？

不是不能，而是选择了不同的取舍。React 的模型是不可变数据 + 显式重渲染：状态变了，组件函数重新执行，生成新的元素树，再由 diff 找出真实变更。

代价是会产生”无谓的重渲染”（所以才需要 memo、useMemo、useCallback）；收益是数据流可预测、可重放、可并发中断——因为组件必须是纯函数，才能在并发渲染里被安全地打断和重做。

而 Vue 的细粒度响应式，更新是”精确命中”的，天然不需要 memo，但组件的执行时机是隐式的，与并发渲染这套机制的兼容性成本更高。React Compiler 1.0 已 GA，它做的事正是在编译期自动插入等价的 memo 逻辑，把”手动优化”这一层负担收掉，而不改变底层模型。

Q8：Vue 的 ref 和 reactive 怎么选？

回答要点：

• reactive 只能代理对象，解构或返回时会丢失响应性（因为 Proxy 是绑在对象上的，解构出来的是普通值）。
• ref 包了一层 { value }，靠引用来承载响应性，可以承载任意类型，传递和解构都不丢。
• 实践上：优先用 ref，除非明确需要一组强关联的字段。团队统一比追求”语法更干净”重要。
• 陷阱：reactive 对象整体替换（obj = {...}）不会触发更新，必须改属性或用 Object.assign。

四、调度与时间切片

Q9：setState 到底是同步还是异步？

这个问题本身问得不准确，标准答法是分版本、分场景：

• React 18 之前：在 React 事件处理函数里是批处理的（表现为”异步”）；在 setTimeout、原生事件、Promise 回调里是同步的，每次调用立即触发渲染。
• React 18 之后：自动批处理（Automatic Batching）覆盖了所有场景，包括 timeout 和原生事件。所以在 React 18+ 里，它总是批处理的。

// React 18+：以下两次 setState 只会触发一次渲染
setTimeout(() => {
  setCount(c => c + 1)
  setFlag(f => !f)
}, 1000)

// 如果需要"立刻读到更新后的 DOM"，用 flushSync
import { flushSync } from 'react-dom'
flushSync(() => setCount(1))   // 同步刷新，跳出批处理

加分点：批处理依赖的是”更新被调度到同一个批次”，而 flushSync 是显式的逃生舱，代价是同步渲染阻塞主线程，别滥用。

Q10：React 的渲染分哪几个阶段？哪些能被打断？

两个阶段必须分清：

1. Render 阶段（可中断）：构建 Fiber 树、diff 出变更、收集副作用。这个阶段是纯计算，可以随时中断、重做、丢弃。对应的生命周期/computed 逻辑必须是纯的——这也是为什么 componentWillMount 这类被废弃。
2. Commit 阶段（不可中断）：把变更一次性刷到真实 DOM，执行 layout effect 和 passive effect。必须一口气做完，否则用户会看到撕裂的界面。

一句话总结：Render 阶段可以重来，Commit 阶段必须一次成功。理解了这点，就能理解为什么副作用要写在 useEffect 而不是渲染逻辑里。

五、2026 年的新考点：编译期优化

Q11：什么是”编译期优化”？Signal 和虚拟 DOM 是对立的吗？

趋势是：把运行时的 diff 工作尽量挪到编译期。几个代表：

• Svelte 5 runes：编译时就分析出状态依赖关系，生成直接操作 DOM 的更新代码，运行时根本没有虚拟 DOM。
• Solid：细粒度 Signal，更新时直接定位到具体的 DOM 绑定，不经过组件重渲染。
• Vue Vapor Mode（3.6）：对标注了 <script setup vapor> 的组件，跳过虚拟 DOM，编译成直接操作 DOM 的代码，与虚拟 DOM 组件可以混用。

关键认知：Signal 和虚拟 DOM 不是非此即彼。Vue 3.6 的做法就是同一套响应式 + 两套渲染策略共存，按组件粒度选择。面试时说出”这是渲染策略的可选项，不是框架路线之争”，会显得认知比较新。

Q12：为什么 React Compiler 能自动做 memo？

因为它在编译期做了数据流分析：分析出哪些值的依赖没变，就把对应的计算结果缓存下来，等价于手写的 useMemo/useCallback/memo，但粒度更细（可以精确到 JSX 内部的某个表达式）。

它的前提是组件必须遵守 React 的规则：纯函数、不在渲染中修改外部变量、Hooks 调用顺序稳定。这也是为什么配套的 eslint-plugin-react-hooks（当前 7.1.1）成了必需项——编译器只能优化它”敢确定”的部分，规则违规的地方会保守地跳过优化。

六、怎么把这一块答出彩

框架原理题的评分标准，通常不是”答对”，而是有没有分层和取舍意识。给三条实操建议：

1. 先给结论，再给约束。不要从实现细节讲起。比如被问 Fiber，先说”它解决的是不可中断的递归导致的长任务阻塞”，再展开数据结构。
2. 主动做对比。能同时说出 React 和 Vue 的不同取舍，说明你理解的是设计空间而不是某个框架的 API。
3. 准备一个真实的踩坑案例。”我们列表用了 index 做 key，导致筛选后勾选状态错位，排查了半天”——这类例子比背十条回答都有说服力。

七、小结

框架原理这一块可以收敛成五句话：虚拟 DOM 换的是开发体验和可预测性而非绝对性能；Diff 靠三条启发式把复杂度降到线性；Fiber 把递归改写成可中断的链表遍历；响应式两大阵营的分歧在”精确更新”与”可重放纯函数”之间取舍；2026 年的主战场已经挪到了编译期。

参考：React 官方文档、Vue 响应式深入、Svelte Runes 文档。版本号以 npm dist-tags 为准，引用前建议再核一次。