Vue 模板是怎么编译成 render 函数的？AST 和 PatchFlag 有什么作用？

知识点详解：编译时知道什么，运行时还能少做什么

模板先成为结构，不是直接变成 DOM

咱们假设模板里有一个固定标题，以及显示 count 的段落。浏览器最终需要真实 DOM，但 Vue 编译器首先处理的是模板文本。

解析以后，AST 表示元素、属性、插值等结构。转换阶段可以识别动态表达式，并组织生成代码所需的信息；最后生成 render 函数。

运行组件时，render 才会根据当前数据产生虚拟节点。随后渲染器把它们挂载到页面，或者与旧结果比较并更新。

Vue 的渲染机制说明区分了编译、挂载和更新。这里最容易混淆的地方是：编译模板并不等于已经生成真实页面。

静态内容没有必要反复重新分析

固定标题不依赖组件状态，可以在编译时被识别。符合条件的静态结构，可以通过静态提升或相关优化复用，减少每轮生成和比较的工作。

但编译器必须能够确认它真的静态。带有动态绑定、指令或其他运行时条件的节点，不应简单按“文字看起来固定”判断。

预编译也有帮助。构建阶段完成模板编译以后，客户端可以使用生成的渲染代码，不必再携带和执行同样的模板编译工作。使用运行时编译的场景则不同，不能把“Vue 项目”一概认为已经预编译。

PatchFlag 说明这个节点哪里可能变化

如果一个段落只有文本插值会变，编译器可以生成动态文本相关标记。运行时看到标记，就知道应重点更新文本。

如果变化的是某个 class 或特定属性，也有对应的标记或动态属性信息。具体生成结果取决于模板和编译器版本，不建议把某次数字值背成业务设计原则。

可以把它理解成编译器留给运行时的便条：“这个节点要关注这些位置。”它不是新的响应式系统，也不是在数据变化时自动写 DOM 的独立开关。

数据变更仍需要触发组件更新；render 仍需产生相关结果；渲染器再利用这些信息减少工作。

块结构解决的是动态节点的范围问题

一棵模板树里可能有大量静态位置，只有少量动态节点。Vue 的块结构能够组织这些动态后代，让运行时不必每次都从整棵树逐个找起。

PatchFlag 关注节点内部哪些内容可能变；块结构关注需要重点处理哪些动态节点。两个机制相互配合，但不是同一个概念。

遇到条件分支和列表，结构本身也可能变化，编译器与运行时需要处理相应边界。不能因为有块优化，就认为所有列表更新都会变成固定次数的操作。列表长度、键、结构变化以及组件自身工作，仍会影响成本。

验证时，可以用 Vue 官方交互式编译工具查看两个小模板的输出：一个只有静态标题，一个带动态文本。观察生成代码差别，再结合更新行为理解；不要在未测量前承诺某个项目会快多少。

面试官继续追问

手写 render 函数还有这些优势吗？

不一定具有相同的编译期信息。模板编译器能够分析模板结构，手写 render 需要开发者自己考虑相应组织方式。不能因为都是虚拟节点就认为优化信息完全一样。

PatchFlag 能代替 key 吗？

不能。key 帮助列表更新时识别节点身份，PatchFlag 提供动态位置提示。它们解决不同问题。

编译优化是不是能解决组件更新过多？

不能全部解决。状态组织、依赖范围、组件划分和副作用都可能造成额外工作。编译优化降低部分更新成本，不会自动改变应用架构。

面试速记卡

• 编译过程：模板解析为 AST，再转换并生成 render。
• 运行过程：render 产生虚拟节点，渲染器操作真实 DOM。
• 静态优化：提前识别不变结构，减少重复工作。
• PatchFlag：提示节点内部哪些位置可能变化。
• 块结构：帮助运行时聚焦动态节点，不替代响应式与列表身份。