夜雨聆风很多人第一次真正翻开 React 或 Vue 的源码，是在面试前一两周的深夜。电脑屏幕幽暗的光里，他们急切地寻找着那些耳熟能详的关键词：Fiber、Diff、Reactivity、Proxy、nextTick……像考前划重点的学生，用荧光笔标记出所有“可能考到”的段落，然后把它们压缩成几段能在30秒内讲述完毕的答案。
面试结束了。如果运气够好，那些连夜吞下的概念成功兑换成了 offer。然后，源码文件夹被关掉——或许是永远地关掉。那些标注过的代码、画过的流程图，渐渐在记忆里褪色，最终沉淀为一个有些模糊的标签：“我读过源码”。
如果源码阅读的终点只是一场面试，那它确实是一项性价比可疑的投入——毕竟市面上有的是更短平快的面试宝典。但我想暂时搁置这种功利性的想象，重新审视这件事：当我带着与代码对话的心智去阅读一个世界级前端框架的源码时，我真正获得的，到底是什么？
1. 我为什么要读源码？——三种动机的自我检测
在翻开第一行代码之前，或许值得先向内看一眼自己的起心动念。我观察到的动机，大抵落在三个区域里：
第一种：危机驱动。 “面试要问，同事在聊，不懂这些就感觉落后了。”这种动机最为普遍，也最容易导致“交差式”阅读——满足于能说出几个术语，能画出几张架构图，却在离开面试室后快速遗忘。因为它追求的是一个静态的结果，而不是一个动态的认知过程。
第二种：问题驱动。 “遇到了一个诡异的 bug，文档里找不到解释，被迫追到源码里寻找真相。”这种动机往往是最健康的入口。因为此时的我不是为了“读”而读，而是为了解答一个真实、迫切的问题。我在源码中焦灼地穿梭，最终在某一个判断分支、某一行注释里找到了答案——那一刻的豁然开朗，会让我对框架的某一小块获得一种难以磨灭的“体感”。
第三种：成长驱动。 “我想知道，为什么他们会这么设计？这么设计的代价是什么？我能从中学到什么？”这是最持久、也最可能产生复利的动机。它不急于求成一个结论，而是享受拆解一个复杂系统时的思维体操。拥有这种动机的人，往往能在源码里待很久，出来之后，眼神都变得不一样。
我不需要立刻成为第三种人。事实上，绝大多数深入的源码阅读者，都是从第一种或第二种动机启程的。真正重要的，是我在阅读过程中，是否愿意把姿态从“寻求一个答案”，逐渐调整为“进行一场对话”。
2. “面试八股文”与“深层内功”：一场不对称的比较
让我们承认一个事实：在面试场景下，源码知识确实能加分。 当我能讲清楚 React 为什么需要 Fiber，为什么 Hooks 不能放在条件语句里，Vue 3 的响应式系统如何通过 Proxy 解决了 Vue 2 的数组监听局限，面试官大概率会投来认可的目光。
但如果我把源码阅读的价值仅仅绑定在这几道“必考题”上，我会错失更珍贵的那部分——因为“面试能记住的，时间久了都会忘”，而“真正留下的，是看问题的角度和解题的范式”。
让我举个例子。假设我在阅读 Vue 3 的响应式系统时，只记住了 ref 和 reactive 的区别、effect 的依赖收集流程，那么我得到的是一份优质的面试回答。但如果我在阅读过程中开始思考这样一个问题：为什么 Vue 选择了“可变数据 + 依赖追踪”的路线，而 React 选择了“不可变数据 + 全局重新计算”的路线？ 我就会触碰到两个框架在哲学层面的分歧。
Vue 的路线更“自动化”——它替我追踪每一个用到的响应式值，值一变，相关的组件就自动更新。但自动化是有代价的：我需要理解响应式边界。比如 Vue 2 基于 Object.defineProperty，对新增 / 删除对象属性存在历史限制，所以才有 $set 这样的补救；Vue 3 改用 Proxy 后缓解了这类问题，但如果把响应式对象的属性解构成局部变量，这个局部变量的读写就不再触发源对象的代理陷阱。React 的路线则更“显式”——状态更新通常会从发生更新的组件开始重新执行渲染逻辑，再由协调过程决定哪些子树可以跳过、复用或提交到宿主环境。它配合不可变数据可以更容易追踪变化历史，但代价是需要我手动通过 useMemo、React.memo 等手段来控制不必要的计算。
当我思考到这个层面时，我学到的就不再是“Vue 使用 Proxy，React 使用不可变数据”这么单薄的知识点，而是两种截然不同的状态管理范式，以及它们各自的权衡取舍。这份理解，会在未来某一天我设计自己的状态管理方案时，从潜意识里浮出来，为我提供两种深思熟虑过的设计方向，而不是让我从零开始盲目试错。
这就是“看问题的角度”和“解题的范式”。 面试官可以考我具体的 API，但几乎不会考我这个。然而正是这些不会直接考的内容，会在我职业生涯的漫长时间里，持续地、安静地为我创造价值。
3. 从“使用框架”到“与框架对话”的层级跃迁
一个开发者与框架的关系，大致会经历四个层级：
- 会用
：能根据文档和教程，完成常规的业务需求。 - 会查
：遇到问题时，能高效地查询文档、Stack Overflow、GitHub Issues，快速找到解决方案。 - 会修
：能定位到框架内部的 bug，或者至少理解为什么某个行为不是 bug 而是设计如此，并能够给出变通方案，甚至提交 PR。 - 会造
：不仅会用框架，还能在设计思想层面与框架对话。当我需要一个框架没有提供的底层能力时，我可以自己写一个自定义渲染器、一个深度定制的插件，甚至受到启发后设计一个适合团队的小型框架。
源码阅读，是跨越“会查”到“会修”，并隐约看见“会造”之门的转折点。
停留在“会查”阶段时，框架对我来说依然是一个“黑箱”。我知道怎么给它输入，也能预判大部分输出，但当输出与预期不符时，我的排查方式主要是搜索和试探。而一旦我开始阅读源码，黑箱上就出现了第一道裂缝——我看见了里面的齿轮如何咬合。某天我遇到一个奇特的渲染滞后问题，我不再只是反复调整 useEffect 的依赖数组试图碰运气，而是会下意识地想：“是不是这次的更新被 React 的调度器划分到了低优先级批次？能否通过 flushSync 强制同步？如果强制同步，会不会破坏 React 对用户交互的保护机制？”当我开始这样思考问题时，框架在我面前就不再是一个需要背诵的“八股文题库”，而是一个我能够与之进行技术对话的、有血有肉的设计系统。
这个跃迁带来的职业底气，远胜于任何面试技巧。
4. 源码阅读的复利效应：能力圈的逐渐扩大
有一个思维实验：如果我花两个月仔细读完 React 或 Vue 的核心源码，两年后我还能剩下什么？
我大概率记不住某个具体函数的参数顺序，记不住某一行精妙的位运算。但我会清晰地记得 React 的调度器是如何通过链表结构实现可中断的遍历；我会记得 Vue 的编译器如何通过分析模板的静态部分来生成“靶向更新”的代码，从而跳过整棵虚拟 DOM 树的比对。这些“大局观”会在我的头脑中形成一种越来越敏锐的直觉。
这种直觉有什么用？当我面对一个旧项目里庞大的表单页面，每次输入一个字符都卡顿半秒时，我不会束手无策地想着“重写算了”。我脑子里会自然浮现出两条思路：要么参考 Vue 的“动静分离”，在编译层面对这个页面做分析，把静态部分摘出去；要么参考 React 的“时间切片”，把表单渲染拆成可中断的小任务，不让用户输入被长任务阻塞。我可能不会真的去实现一个完整的编译优化或调度器，但这种思考的起点，已经让我和大多数只会搜索“react 表单卡顿怎么优化”的人拉开了本质的差距。
这就是复利：我读过的每一行核心代码，都在为我未来的技术判断力存入一笔微小的本金。时间越长，利息越厚。它不会让我明天就涨薪，但它会确保我在每次技术选型、每次疑难杂症面前，都拥有比别人更深一层的分析维度。
5. 下一步：从”为什么”到”怎么读”
在第 0 篇总序中，我已经画好了全系列的路线图。接下来，我们从方法入手：面对 React 和 Vue 几十万行的源码，应该从哪里开始读，才不会一头扎进迷宫？
关注硅基罗盘
如果这篇文章有所帮助，欢迎关注公众号 硅基罗盘。也欢迎把文章分享给同样关心工程思维的朋友，并在评论区留下问题、经验或反例；这些反馈会成为后续选题和修订的重要线索。
