全文近万字。。。来都来了，点个赞再走吧

我很早就意识到，能纯熟、高效浏览开源前端框架源码是成为一个高级前端工程师必须具备的基本技能之一，所以在我职业生涯的最晚期，就曾经开始做了很屡次相干的尝试，但后果通常都以失败告终，起因形形色色：

• 不足必要的背景常识，犹如浏览天书
• 不了解我的项目架构、设计理念，始终不得要领
• 指标不够聚焦，浏览过程容易复杂化
• 容易陷入细节，在不重要的问题上纠结半天
• 容易追着分支流程跑，扩散注意力
• 没有及时记录笔记和总结，没有把常识碾碎、重组、内化成本人的货色
• 没有解决过特地简单问题的经验，潜在的不自信心理
• 集体毅力、韧性有余，或者指标感不够强烈，遇到困难容易放弃
• 等等

这个列表还能够持续往下拉很长很长，总之既有我本人主观认知上的限度又有切切实实的客观原因。起初因为工作的契机硬着头皮看完 Vue 和 mxGraph 的源码，发现事件并没有本人设想中那么艰难，起初前前后后陆续看了很多框架源码，包含 Webpack、Webpack-sources、Vite、Eslint、Babel、Vue-cli、Vuex、Uniapp、Lodash、Vetur、Echarts、Emmet 等等，迟钝如我也缓缓摸索出了一些普适的形式办法，进而斗胆撰下这篇文章，不敢说授人以渔，但至多也该抛砖引玉吧。

所以这是一篇为哪些无意，或筹备，或曾经在浏览前端框架源码的同学而写的文章，我会在这里抛出一些通过我集体屡次实际总结进去的浏览技巧和准则，并联合 Vetur 源码，具体地解说我在浏览源码的各个阶段所思所想，心愿能给读者带来一些启发。

弄清楚指标

在介绍具体的技巧之前，有必要先跟读者探讨一下浏览源码的动机，想分明到底需不需要通过这种形式晋升本身技能，尽管学习优良框架源码的确有十分多不言自明的益处，但每个人的教训、所处的语境、诉求、思维习惯不同，理论学习效果在不同个体或个体的不同期间必然存在极大的差别，这外面最大的变量一是教训，二是指标，教训因人而异，且很难在短时间内补齐，没有太多探讨空间；倒是指标方面值得盘道盘道。

第一层，先弄清楚为啥要浏览源码？可能的起因有很多，例如：

• 为了增进对框架的认知深度，晋升集体能力
• 为了应答面试
• 为了解决当下某个辣手的 bug 或性能问题
• 基于某些起因，须要对框架做二次革新
• 反正闲着，也不晓得该学点啥，试试呗。。。
• 好奇

这外面有一些很形象，例如最初一个“好奇”；有一些很具体，例如“为了做二次革新”；还有一些在具体与形象之间。依照 SMART 准则的说法，越具体、可掂量的指标越容易达成，如果读者的指标还处在比拟不置可否，不够具体具体的阶段，那执行过程大概率会翻车，毕竟这是一件特地耗费精力与耐性的活儿。

对于这种状况，我的倡议是无妨往更细节的档次再想一想，例如对于最初一点“好奇”，能够想想具体有哪些个性让你特地神奇，值得花工夫精力去粗疏地摸索，放在 Vetur 语境下能够是“我想理解 Vetur 的 template 谬误提醒与 eslint 如何联合在一起，实现模板层面的谬误提醒性能”，这就很具体很容易掂量了。

第二层，读者如果曾经有了明确、具体、可掂量的指标，无妨在开始之前先自问几个问题：

• 当下的确须要以浏览源码的形式增进本人对框架的认知深度吗？有没有一些更轻量级，迭代速度更快的学习形式？
• 你所选定的框架，其复杂度、技术难度是否与你当下的能力匹配？最好的状态是你自认为踮踮脚就可能到，过高，不具备可行性；过低，ROI 不值当。

如果通过这番斟酌之后，必要性、可行性、相关性都与集体指标符合，那就没啥可犹豫的。

第三层，须要辩证地去对待所谓“指标”—— 不是把整个我的项目残缺读完读通才叫胜利，如果能从一些语句、片段、部分模块中习得新的设计思维、工具办法，甚至仅仅是命名标准都能够算作集体的一点提高，千里之行; 始于足下远比拔苗助长靠谱的多。所以一开始没必要把指标定的太高，能刚刚好满足本身需要是最好的，过程中如果发现问题域的复杂度在一直收缩变大，继续投入很多工夫却始终没有显著功效的话，那倡议果决放弃或者申请外援，从新评估指标与可行性之后再做决定。

总之，这是一个预期治理的问题，咱们能够多参考 SMART 准则，多从具体、可掂量、可行性、相关性几个维度思考，一直斟酌是否须要做这件事；如何拆解指标，用指标反推打算，一直推动集体胜利。

浏览技巧

理解背景常识

常识 是造成 了解 的必要条件，开展学习任何一个开源我的项目之前都有必要花点工夫调研我的项目相干的基础知识，渐进构建起一套属于你本人的常识体系，这包含：

• 优质参考资料 —— 收集一波品质较高的学习材料，收集过程能够同步通读一遍
• 框架是如何运行的 —— 也就是所谓的入口
• IO —— 框架如何与内部交互？它通常承受什么状态的运行参数？输入什么模式的后果？
• 生态 —— 优良的框架背地通常都带有一套成熟的生态系统，例如 Vue，框架衍生品如何补齐框架自身的性能缺失？它们以何种形式，以什么样的 IO 与主框架交互？遵循怎么样的写法规定？
• 如何断点调试 —— 这简直是最无效的分析方法，断点调试可能帮忙你粗疏地理解每一行代码的作用。

留神，这里的指标是迅速构建起对于这个开源我的项目的形象 —— 甚至不太精确的常识框架，有意思地防止陷入无尽的细节中，就像在浏览一篇文章的时候，能够先看看目录构造粗略地理解文章的信息框架，理解文章大略内容。

例如，我刚开始学习 Vetur 的时候只晓得这是一个 VS Code 插件，但齐全不理解插件怎么写、怎么运行、怎么实现语言个性，所以我做的第一件事件是仔仔细细浏览 VS Code 的官网文档(所幸文档十分齐全，不像某驰名打包工具)，学习对于插件开发的基本知识，包含：

进一步总结对于 VS Code 语言插件的因素：

• 怎么写插件：通过 package.json 文件的 contributes、main 等属性，申明插件的性能与入口
• 怎么运行：开发阶段应用 F5 启动调试
• 怎么编写语言个性 ：应用 词法高亮、Language API、Language Server Protocol 三类技术实现

VS Code 畛域的常识量还是很宏大的，学习背景常识并梳理成这种高度结构化、高度形象的脑图可能给你一个更高层、全面的视角，现实状态下，后续理论剖析源码的时候这些骨架脉络可能让你十分本能地映射到某一个切面的知识点，事倍功半。

六步循环剖析

接下来，我会介绍一套我罕用的剖析流程：

整体分为六个步骤：

• 了解我的项目构造
• 寻找适合的切入点
• 就着切入点查阅文章材料
• 就着切入点剖析代码流程
• 部分深入研究
• 及时总结
• 之后，再持续设定切入点，反复执行上述流程直到透彻地了解了问题

这是一套在 总 - 分 - 总 视角之间重复横跳最终构建出残缺视角的方法论，重点就在于通知读者在什么阶段应该关注什么，疏忽什么，输出什么，输入什么，我集体就是依照这个办法缓缓摸索出包含 Webpack、Babel、Vue、Vetur、mxGraph 在内的各种开源框架的实现原理。

了解我的项目构造

刚开始浏览源码的时候，置信大多数人都会很懵逼，无从下手，这是因为读者对我的项目不足一个必要的框架性认知，不理解程序的入口在哪里、要害组件有哪些、各个文件夹有什么作用等，遇到问题无奈迅速揣测实现门路。

所以，浏览源码的第一个步骤，应该是先花点工夫浅显地剖析、了解我的项目的组织构造。所幸一个值得深刻浏览学习的开源我的项目，通常都会有较强的整体性与一致性，咱们只须要梳理出三条线索：

• 剖析我的项目入口
• 剖析我的项目依赖了哪些根底工具，包含编译工具，如 webpack、Typescript、babel；根底库，如 lodash、tapable、snabbdom。
• 将我的项目中重要文件夹、文件逐个列举进去，了解它们如何依照依赖关系组成一个整体的架构。

放在 vetur 语境下，咱们在下面“理解背景常识”一节曾经理解到 VS Code 插件须要在 package.json 文件通过 contributes 等属性申明插件的配置信息，所以这几个问题都能在 package.json 文件找到答案。

入口剖析

首先，须要辨认出 Vetur 利用的入口，这一步的作用是帮忙咱们了解 Vetur 是如何向 VS Code 奉献新个性的。剖析 vetur 的 package.json 发现有三种间接指向到文件的配置项：

• contributes.languages 指定语言配置文件
• contributes.grammars 指定语法配置文件
• "main": "./dist/vueMain.js" 指定插件执行入口

三个入口别离实现三种不同的语言个性性能，略显简单，这里有必要别离开展理解一下。

摸索 contributes.languages 配置

一一解说，contributes.languages 配置信息指向到 ./languages/***-language-configuration.json 文件，如：

{
    // ...
    "contributes": {
        "languages": [
            {
                "id": "vue",
                "configuration": "./languages/vue-language-configuration.json"
            },
            {
                "id": "vue-html",
                "configuration": "./languages/vue-html-language-configuration.json"
            }
            // ...
        ]
    }
    // ...
}

这里回过头翻一下 VS Code 对 [contributes.languages](https://code.visualstudio.com/api/references/contribution-points#contributes.languages) 的解释(感激资源丰盛的 VS Code 社区)：

Contribute definition of a language. This will introduce a new language or enrich the knowledge VS Code has about a language.

粗心是说 contributes.languages 配置项的作用次要是增进 VS Code 对具体语言的了解，至于怎么加强呢？持续关上配置项中的 ./languages/vue-language-configuration.json 文件：

{
    "comments": {
        // symbol used for single line comment. Remove this entry if your language does not support line comments
        "lineComment": "//",
        // symbols used for start and end a block comment. Remove this entry if your language does not support block comments
        "blockComment": [
            "/*",
            "*/"
        ]
    },
    // ...
}

文件中定义了行内 comment、块级 comment、括号、折叠等语言规定的配置，规定都很简略直白，篇幅关系这里不开展。

回顾一下摸索步骤：

• 翻阅参考资料，了解 contributes.languages 配置的作用
• 关上对应入口文件，猜想各个配置项的作用
• 持续翻阅参考资料，或者批改配置，验证猜测

摸索 contributes.grammars 配置

contributes.grammars 项蕴含诸多指向到 ./syntaxes/vue-xxx.json 的配置信息，形如：

{
    "contributes": {
      "grammars": [
        {
          "language": "vue",
          "scopeName": "source.vue",
          "path": "./syntaxes/vue-generated.json",
          "embeddedLanguages": {
            "text.html.basic": "html",
            // ...
          }
        },
        {
          "language": "vue-postcss",
          "scopeName": "source.css.postcss",
          "path": "./syntaxes/vue-postcss.json"
        }
        // ...
      ]
    }
  }
  

同样的，咱们先查一下官网对 [contributes.grammars](https://code.visualstudio.com/api/references/contribution-points#contributes.grammars) 配置项的解释：

Contribute a TextMate grammar to a language. You must provide the language this grammar applies to, the TextMate scopeName for the grammar and the file path.

这段形容稍微简单，粗心是开发者能够通过 grammars 属性提供对于语言的 TextMate 模式的语法形容，grammars 配置项蕴含三个属性：

• language：语言的名称
• scopeName：语言的分类，与 TextMate scopeName 同义，可用于嵌套语法定义
• path：语言的词法规定文件

这外面 path 属性指向一个内容更简单的配置文件 ./syntaxes/vue-xxx.json，咱们能够接着关上其中任意一个文件，要害内容构造如下：

{
    "name": "Vue HTML",
    "scopeName": "text.html.vue-html",
    "fileTypes": [],
    "uuid": "ca2e4260-5d62-45bf-8cf1-d8b5cc19c8f8",
    "patterns": [
        // ...
        {
            "name": "meta.tag.any.html",
            "begin": "(<)([A-Z][a-zA-Z0-9:-]*)(?=[^>]*></\\2>)",
            "beginCaptures": {
                "1": {"name": "punctuation.definition.tag.begin.html"},
                "2": {"name": "support.class.component.html"}
            }
        }
    ],
    "repository": {// ...}
}

依照 Syntax Highlight Guide(https://zjsms.com/e7E5Jdq/) 一节的说法这外面最重要的是 patterns 属性，而 patterns 属性最要害的性能就是以正则语句表白语言的词法剖析规定，并调配词法对应的 name 命名，具体的配置规定还能够持续参考 TextMate 官网，这里大抵了解作用即可，先不开展深究。

摸索 main 配置

接着往下看，第三个值得关注的是 main 属性，在 vetur 中对应的值为：

"main": "./dist/vueMain.js"

VS Code 官网对 main 属性的解释十分精简：The entry point to your extension，也就是插件的入口，通常须要指向到可执行的 JS 文件，插件启动时 VS Code 会执行这个入口文件导出的 activate 办法，内容框架大抵为：

import vscode from 'vscode';

export async function activate(context: vscode.ExtensionContext) {// ... 启动逻辑}

在 Vetur 中，activate 函数定义在 client/vueMain.ts 文件，剖析源码可知该函数次要实现如下事项：

• 调用 registerXXXCommands 办法注册一系列命令
• 调用 initializeLanguageClient 办法初始化 LSP Client 对象

这两个操作具体的作用，咱们先按下不表，前面再开展。

小结

对入口的剖析就到这里了，咱们先总结、记录下要害信息：

• Vetur 实质上是一个 VS Code 插件，所有配置 —— 包含入口都记录在 package.json 文件中

• Vetur 蕴含三种启动入口：

  • contributes.languages：定义一些简略的语言根本配置，包含怎么折叠，怎么正文
  • contributes.grammars：定义了一套基于 TextMate 引擎的词法规定，用于实现代码高亮
  • main：定义了插件的启动入口，入口中注册了一系列命令，同时创立了基于 LSP 协定的 Language Client 对象，而 LSP 协定用于实现如代码补全、错误诊断、跳转定义等高级个性

到这里，尽管咱们还是不理解 Vetur 的实现细节，然而对 Vetur 的背景常识与我的项目构造应该曾经有了一个比拟根底的认知，曾经能大抵辨认哪些性能由哪些模块实现。

OK，这里先放弃好这个隐隐约约的认知就行了，不要花太多工夫。

根底依赖剖析

接下来，须要梳理一下 Vetur 的根底依赖，这一步的作用是帮忙咱们了解 Vetur 可能用到哪些根底技术，比方用到哪些工程化工具、怎么编译、怎么查看代码等。

Vetur 的 package.json 文件次要蕴含三类信息：

• VS Code 插件配置信息，大体上在上一节都有形容，这里不开展

• 工程化命令，外围有：

  • watch：对应命令为 rollup -c rollup.config.js -w，由此能够推断 Vetur 基于 Rollup 实现构建
  • compile：性能与 watch 类似
  • lint：对应命令为 tslint -c tslint.json **.ts，由此能够推断 Vetur 基于 tslint 实现代码查看
• 我的项目的 devDependencies 依赖，次要蕴含 typescript、tslint、rollup、vscode-languageclient、husky、mocha、vscode-test、prettier

那么，从这些信息咱们根本能够推断出如下信息：

• Vetur 应用 Rollup + typescript 等工具执行构建工作，按常理执行 yarn watch 命令应该就能启动一个继续的构建工作过程
• Vetur 应用 tslint 实现代码查看，配合 huscky + prettier 实现格式化工作
• Vetur 应用 mocha + vscode-test 实现自动化测试

文件构造

接着，还须要略微开展看看 Vetur 的文件构造，这一步可能肯定水平上帮忙咱们了解 Vetur 的代码架构及因素，揣测各种个性是在什么地位实现的。Vetur 的文件构造大抵上如下：

vetur
├─ .vscode
│  ├─ ...
├─ build
│  ├─ ...
├─ client
│  ├─ client.ts
│  ├─ commands
│  │  ├─ ...
│  ├─ grammar.ts
│  ├─ ...
├─ languages
│  ├─ vue-html-language-configuration.json
│  ├─ ...
├─ scripts
│  ├─ build_grammar.ts
│  └─ tsconfig.json
├─ server
│  ├─ .gitignore
│  ├─ .mocharc.yml
│  ├─ .npmrc
│  ├─ bin
│  │  └─ vls
│  ├─ package.json
│  ├─ rollup.config.js
│  ├─ src
│  │  ├─ ...
├─ syntaxes
│  ├─ markdown-vue.json
│  ├─ pug
│  │  ├─ ...
│  ├─ ...
│  └─ vue.yaml
├─ test
│  ├─ ...
├─ vti
│  ├─ README.md
│  ├─ bin
│  │  └─ vti
│  ├─ package.json
│  ├─ rollup.config.js
│  ├─ src
│  │  ├─ ...
│  ├─ tsconfig.json
│  └─ yarn.lock
├─ tsconfig.options.json
├─ package.json
├─ ...
└─ yarn.lock

其中，比拟要害的有：

• client：VS Code 插件的入口代码，package.json 文件中 main 字段会指向这个目录的产物
• server：LSP 架构中的 Server 端，上述 client 会通过 LSP 协定与这个 server 目录通信
• syntaxes：Vetur 的词法规定文件夹，外部蕴含许多 JSON 格局，合乎 TextMate 规定的词法申明
• languages：Vetur 提供的语言配置信息，规定比较简单，理解作用即可，不用深刻
• vti：按 vti/bin/vti 文件能够推断，这里是 Vetur 的命令行工具，不在主流程内能够先疏忽
• docs：按内容能够推断这是 Vetur 的介绍文档，此处可疏忽
• build：构建命令，package.json 文件的 script 命令有一些会指向这个目录，能够疏忽
• 一系列根底配置文件，包含 tsconfig.json、package.json 等，可先疏忽

咱们还能够持续往下摸索各个子目录的内容，然而留神浅尝辄止即可，前面随着源码浏览的深刻，读者对各个目录的了解应该会一直迭代增长，当初没必要花太多工夫。

小结

回顾一下，咱们首先学习了一些背景常识，之后花了一些工夫剖析我的项目的入口、根底依赖、文件构造，到这里咱们基本上能够推断出：

• Vetur 是一个语言插件，所以必然是应用 词法高亮、Language API、Language Server Protocol 三类技术实现外围逻辑的，而 package.json 文件中的 contributes 配置项的内容也恰好验证了这一点
• 词法高亮 相干的代码集中在 syntaxes 文件夹
• Language Server Protocol 相干的代码集中在 client 与 server 文件夹
• 能够用 yarn watch 命令继续构建，配合 F5 快捷键启动调试

这些信息是后续剖析源码的必要条件，而这个过程跟学习一门新语言很相似，读者能够回忆一下最开始学习 JavaScript 的时候，有教训的学习者不会一上来马上深刻诸如原型、变量晋升、事件循环等语言细节，而是先以更高层、更形象的视角学习 JavaScript 语言的根本骨架，包含函数、循环语句、分支判断语句、对象等，从而构建起一个形象的结构化认知，后续再缓缓填充细节，有点自顶向下的滋味。

设定切入点

在对我的项目背景与构造有根本理解之后，咱们能够正式开始剖析源码了。首先，读者要找到一个匹配本身状态和需要的切入点，实质上就是将大指标拆解成一系列小指标，将大问题拆解成一系列更具体的小问题，而后带着具体问题更聚焦地去看代码。

所谓切入点能够间接对标到框架的具体性能，或者某些底层机制的实现上，以 Vetur 为例，它实现了诸多辅助开发 Vue SFC 组件的个性，包含代码补全、错误诊断、代码高亮、跳转到定义、hover 提醒等等，这外面任意一个开展来都有大量能够开掘的空间，如果从一开始就漫无目的瞎逛乱看那铁定是看不出个所以然的，鉴于我的指标就是想通过 Vetur 学习 VS Code 插件的开发套路，所以抉择了一个看起来比较简单的个性：代码补全 作为第一个切入点，后续的学习经验证实这是一个十分适合的点，不简单然而曾经能帮我窥见 Vetur 的外围工作机制，以此类推前面剖析其它高级个性如代码高亮、代码补全等，基本上就是很驾轻就熟的状态了。

如果你有一些更明确的目标，比方解决某个具体的 bug，那你应该会更容易 get 到当下最须要做的事件；如果始终抓不到要点，那么倡议先回到后面“理解背景常识”或“了解我的项目构造”的步骤，持续摸索一些上下文信息，再试试问本人：我接下来到底应该先理解哪些具体性能的实现逻辑？

记住，这并不是一锤子买卖，如果你在后续的剖析过程中发现这个切入点变得越来越简单，超出最开始的预期，不要有心理累赘，这再失常不过了，而且反而侧面体现出你对问题域有越来越少的了解了，能够回过头来从新调整指标，找一个更小的切入点。

善用搜索引擎

定下切入点后，首先要做的不是关上代码咔咔就干，而应该首先试试在社区搜寻相干的材料，毕竟自媒体时代了，很多开源框架的常识曾经被有数人吃透、捏碎、重组成各种维度的文章，顺着这些文章的思路去了解源码会比齐全靠本人摸索效率高很多。

列举几种我罕用的搜寻渠道：

• 谷歌 and 百度一类的搜索引擎，体感上谷歌的搜寻品质会好很多，不过有肯定的英语门槛
• 开源我的项目的官网、社区、wiki、github 等官网渠道，通常都会有比拟不错的材料
• Segmentfault、知乎、掘金、公众号等垂直社区
• 国外的 Medium/StackOverflow 社区，品质极高，很多大佬在下面沉闷

如果搜了一通找不到答案，能够试试不同的关键词组合，我常常用的关键词有：

• Xxx 源码解析
• Xxx 原理
• 如何实现 xxx

如果还是找不到，还能够试试换一个意思靠近的关键词，绕点弯路。总之就是想尽办法找到有用的，适宜当下问题的信息，帮忙读者更快更平滑地深入研究源码，这一步对老手尤为重要。

顺便采购一下我的公众号：【Tecvan】，长期聚焦各类前端框架源码的研读解析，欢送订阅。

剖析要害流程

后面说了一大通，到这里终于要开始正儿八经地深入研究代码了。

其实源码剖析的过程特地像侦探电影，最开始你须要面对一堆凌乱，看起来相干又不太相干的线索，侦探须要从这千头万绪中找出惟一事实答案，这个过程通常有两种卓有成效的做法，一是自顶向下，从工夫线、流程的角度登程演绎出大抵的事件框架，之后再深入研究细节，由形象到具体；一是自底向上，找到疑点再往上逐层斟酌，梳理出事件的全貌，由具体到形象。

两种形式各有实用场景，如果出于学习目标，就是想理解某些性能个性的实现原理的话，就应该自定向下，从利用入口登程逐渐向下跟踪梳理出执行流程，了解大框架之后深挖具体细节；而如果是追究繁多 bug 的时候就应该找到出问题的中央，自底向上追溯出全貌再加以更改。

我集体会更偏向于自顶向下的形式，例如我在学习 Vetur 的时候，首先是选定了 代码补全 这一类性能作为切入点，之后从 server/main.ts 开始一路沿着主流程向下逐级摸索，最终达到理论执行代码补全的地位，尽管理论学习过程没有当初说的这么顺利，但最终还是缓缓推导出了这样一个流程图：

这个流程图十分重要，它基本上让我理透 Vetur 的两个重要阶段：

• 启动阶段，vls 类型会初始化化 projectService 对象，之后再监听各类 LSP 事件

• 执行阶段，LSP 事件触发时，vls 会将事件间接委托给 projectService 对象解决，而 projectService 会做两件事件：

  • 针对 SFC 文件做 region 切割，解析出 template、script、style 等区块
  • 针对不同区块，调用 modes/xxx 对象的 doComplete 函数解决

基于这个流程图，逻辑上能够推断出：所有 LSP 申请最终都会依照代码的类型流转到相应的 **modes** 文件夹上，例如：

• 对于 template 的格式化申请，最终会流转到 modes/template/index.ts 文件的 format 函数做解决
• 对于 style 的格式化申请，则流转到 modes/style/index.ts 文件的 format 函数
• 同理能够推导出包含代码补全、hover 提醒、跳转到定义、错误诊断等等高级个性上

这个发现让整个 Vetur 的代码架构变得很扁平，后续钻研具体个性的时候能够跳过后面这一对 LSP 申请的解决、宰割步骤，间接找到对应的 modes/xxx/index.ts 代码。

那么，如何剖析代码的执行流程呢？我集体总结的办法有两个：动态猜测 + 动静验证，放在下一节细讲。

部分深刻

经验后面一系列步骤，储备了足够的背景常识与框架认知后，咱们能够开始逐行剖析源码，理解每一行、每一个变量、每一个函数、每一个模块的具体作用与实现了。接下来我会介绍两种卓有成效的方法论：

• 动态猜测：“读”源码，从面上了解代码逻辑并作出猜测
• 动静验证：“运行”源码，借用 debug 工具逐行跟踪代码执行过程，必要时能够改变原有代码，验证猜测

这两种办法并不若明若暗，通常是一边看代码，一边做揣测，有疑点马上运行起来验证猜测是否正确，灵便配合应用成果更佳。

动态剖析 —— 做猜测

所谓的动态剖析，说白了就是逐行逐句剖析代码，钻研每一个变量、每一个过程的作用，是一个特地吃基础知识和信息检索能力的苦力活。尽管每个框架的实现细节不一样，但还是有一些普适的技巧能够讨论一下：

• 函数层面，关注输入输出及副作用：

  • 函数承受什么构造的参数，这些参数通过函数外部的每一条语句之后会产生什么变动，或者如何影响语句的执行
  • 函数执行结束之后，会返回什么构造的后果，这些后果下一步会被谁生产，影响谁的执行逻辑
  • 特地的，有不少库的函数实现有显著的“副作用”，不是那么“纯”，包含 Webpack、Vetur、Eslint 等 —— 这会急剧晋升了解老本，所以浏览的时候多留个心眼
• 分支语句中，优先关注主流程，分支流程很容易减少心智累赘，到前面就不认得谁是谁了
• 对于循环语句，通常能够关注循环之前的状态与之后的状态，通过这些变动推断循环的作用
• 对于变量与子函数，依据命名推断作用，通常不用适度细究
• 跳过参数校验、错误处理等分支逻辑，抓主流程！抓重点！
• 谨记你要钻研的切入点，遇到特地简单的子模块，先大抵了解性能，点到为止，记下这个硬骨头回头再作为一个新的切入点持续钻研
• 学点罕用的设计模式，工厂、装璜器、代理等等，这些模式的使用率十分高

联合这些技巧，在剖析过程中读者应该还是会遇到很多揣测和问题：这个函数是干什么的；这个语句太简单了，看不懂；这个循环太多 side effect 了，捋不出重点。有问题是坏事，证实你开始能看出端倪了，这个时候就须要将框架运行起来，并且逐渐、动静地察看代码的流转，验证你的猜测或者问题。

动态分析 —— 验证猜测

经验后面动态浏览代码后，置信读者曾经有一些对代码逻辑的根本推断与问题，接下来就须要运行框架，在任何有疑难的中央增加断点，察看执行栈、参数变动、环境变动、逻辑分支语句，确定输出参数是如何确定的，输入后果又会被谁生产。

不过，要批改、运行起一个开源框架可能并不容易，通常须要关注三个点：

• 如果框架曾经接入了一些工程化工具，须要弄清楚如何将源码编译为运行产物，例如 Vetur 我的项目接入了 tsc + rollup，对应的命令为 yarn watch/compile
• 如何启动调试模式，例如 Vetur 场景下须要借用 VS Code 的 .vscode/launch.json 配置文件 + F5 命令启动调试；而对于前端框架如 Vue、React，通常关上浏览器的 DevTool 面板即可
• 如何插入调试语句，前端或 Node 场景下通常增加 debugger; 语句即可

如果一段代码你运行不起来，那么你大概率是无奈把握它的，所以我才会在后面“理解背景常识”一节特意强调须要理解我的项目的入口、启动、调试办法，而一旦把握了调试技能，那这份代码在你背后就相当于脱掉了所有外装，能够逐行、逐句察看代码逻辑的动静流转。

及时总结

好忘性永远不如烂笔头，后面花了这么多工夫一直摸索、验证，如果没有及时做笔记，那这大概率会是一场无用功；而如果没有及时做总结，那大概率无奈将信息内化为你脑子外面的常识！

当然了，也没必要把这事看得太难，总结的目标是对曾经把握的系统信息做一次形象，撇除局部细节，进而整合、梳理成体系化的常识，重点在于内化成本人的常识而不是具体模式状态！所以不要完满留神，不要纠结把语句写的更丑陋，把图画的更好看，在确保根本逻辑通顺的前提下怎么快怎么来。

我集体的习惯是针对一个主题会单开一个本人可见的飞书文档，浏览过程一直记笔记 —— 都是一些没有任何润饰的大白话，一旦自我感觉达到一个节点就马上做一次总结，将代码流程归类为 N 个步骤 —— 尽量管制在 10 个以内，每个步骤写分明逻辑和输入，条件容许的话还会同步画一些毛糙的流程图、时序图、状态机等。最初，攒到一定量级后我还会更进一步地，输入对外的文章或 PPT，作为对本人学习成绩的验收。

下一个切入点

人类所知的物质，或人类发明的产品中，没有一样是相对简略的，优良的开源我的项目通常是非常复杂的组合体，如果仅仅停留在“怎么实现某个具体性能”，那远还没有把握精华，你还须要持续摸索，剖析它“怎么实现、组合多个单体性能”——但不是各自为政，互不相干的“多个”，而是相互交融成有机整体的“多个”。

所以在了解某个切面后，咱们能够持续沿用下面的剖析步骤，循环敲定下一个切入点，能够是你之前遗留下来的简单问题，或者某个新的性能个性，沿着这些碎片顺藤摸瓜，逐渐梳理成一套比拟体系化的认知。

放在 Vetur 语境下，过后通过第一遍剖析之后我基本上就把握了 Vetur 的架构、外围流程及 代码补全 的实现细节，理解到“ 所有 LSP 申请最终都会依照代码的类型流转到相应的 **modes** 文件夹上”这一根本规定。接下来我想持续开掘其它个性的实现原理，包含错误诊断、跳转定义、智能提醒等，于是从新设定切入点，从新跑一边搜寻、流程剖析、部分深刻，周而复始并最终总结出一系列知识点，汇总组织成在线分享：《如何开发一款 VS Code 语言插件 —— 以 Vetur 为例》，人生第一次直播。

最佳实际

再聊聊我集体比拟认可的最佳实际吧：

• 设定好具体、可掂量的指标，不要为了学习而学习，如果有切实的强诉求，那就别因为徘徊，马上去做
• 磨刀不误砍柴工，不要上来就对着源码疯狂输入，肯定要花点工夫站在高层视角去看框架的背景和生态
• 抓大放小，疏忽哪些还不相熟的概念、语句、工具、分支逻辑，你要意识到复杂事物的学习模型往往螺旋回升，逐渐深刻的，不可能过一遍就能把握所有细节和精华，如果一开始就适度关注细节，通常会让整个学习周期拉到有限长。要弄清楚啥时候，什么状况下应该疏忽细节，什么时候应该抓住不放 —— 这与你的指标和切入点有很大的关系
• 随时笔记：一旦有任何新发现、新问题，做好笔记，记录下来，这些都会成为持续摸索的重要线索

• 随时总结：

  • 笔记记录当下的、系统的发现，总结则将这些线索串联造成知识点。
  • 总结过程你会发现更多认知破绽，提出更多问题，能够反过来持续开掘
  • 好忘性不如烂笔头，摸索的后果落到纸面上才会真正成为你本人的货色，极其一点看，没有造成输入的学习过程往往会随着工夫的流逝，变成徒劳

学习毕竟很集体的事件，下面提到的这些办法、技巧、准则对我集体特地受用但实际效果必然还是因人而异的，如果读者执行过程中感觉特地膈应特地好受，那齐全能够适当微调，缓缓找出更适宜本人的形式办法。