本文目录导读：
这是一个很有深度的问题，要剖析浏览器引擎，不能只把它当黑盒看，而需要从架构分层、核心流程、关键技术三个维度切入。
下面我会从“宏观架构”到“微观细节”逐步帮你拆解浏览器引擎的工作原理。
宏观架构：浏览器的“五层楼”
一个大致的浏览器架构（以Chrome/Chromium为例）分为以下几个进程/模块,浏览器引擎是其中最核心的部分：
- 浏览器进程：管理标签页、地址栏、网络请求、文件读写等。
- 渲染进程（核心）：包含浏览器引擎，负责解析HTML、CSS、执行JavaScript、布局、绘制和合成。你问的“浏览器引擎”主要就是指这个进程里的逻辑。
- GPU进程：处理3D CSS、WebGL等图形渲染请求。
- 网络进程：负责网络请求（HTTP/HTTPS）。
- 插件进程：运行Flash、PDF等插件（已逐渐被废弃）。
核心结论：浏览器引擎 = 渲染进程 里的那套把HTML/CSS/JS转化成屏幕像素的机制。
浏览器引擎的核心剖析（渲染流水线）
浏览器引擎的核心工作就是将网页源代码渲染为像素，这个过程是流水线式的，但现代引擎（如Blink、WebKit）会进行高度优化（如异步、并行、增量处理）,下面是经典的主干流程：
HTML -> [HTML解析器] -> DOM树
\
CSS -> [CSS解析器] -> 样式规则 -> [样式计算] -> 带样式的DOM树 -> [布局] -> 布局树 -> [分层] -> 层树 -> [绘制] -> 绘制指令 -> [栅格化] -> 位图 -> [合成] -> 屏幕像素
/
JS -> [JS引擎] -> 修改DOM/CSSOM (重新触发流程)解析：构建结构化树
- HTML解析器：它不是简单的字符串匹配，它会读取字节流，进行词法分析（Tokenization）拆分成标签、属性、文本等Token，然后进行语法分析（Tree Construction）构建出DOM树，这个过程是容错性极强的（比如
<br>没闭合，浏览器不会崩溃）。 - CSS解析器：将CSS文本解析为CSSOM（CSS Object Model）树（样式规则树）。
- JS引擎（如V8）：解析并执行JavaScript，它会操作DOM API和CSSOM API，改变了DOM/CSSOM就会重新触发后续流程（重排或重绘）。
关键点：DOM树和CSSOM树是独立构建的，但会相互阻塞（CSS会阻塞渲染，JS会阻塞DOM解析）。
样式计算：让元素“穿上衣服”
- 计算每个DOM节点的最终样式：把CSSOM中的规则（继承、层叠、优先级）应用到每个DOM节点上。
- 结果：生成一棵带计算后样式的DOM树（也叫“渲染对象树”或“RenderObject树”），每个节点都明确知道自己的
color、font-size、display、position等。
优化：现代引擎使用样式共享（Style Sharing）来避免重复计算（如果两个DOM节点样式完全一样，复用结果）。
布局：确定“位置和大小”
- 递归计算：遍历带样式的DOM树，根据CSS盒模型（
width,height,margin,padding,border,position,display: flex/grid等）计算每个元素在视口中的几何位置（x, y, width, height）。 - 结果：生成一棵布局树（Layout Tree），注意：
display: none的元素不会出现在布局树里；而:before/after等伪元素会。 - 核心：流式布局（从左到右、从上到下）、浮动、定位、Flexbox、Grid这些布局算法都在这里实现。
分层与绘制：将每个元素绘制成“指令”
- 分层：为了提高滚动、动画性能，引擎会把页面按照层叠上下文（
z-index、opacity、transform、will-change等属性）划分为多个合成层（GraphicsLayer）。- 类比：像Photoshop里的图层，单独滚动的
overflow: scroll、position: fixed的导航栏、transform: translateZ(0)通常会被提升为独立层。
- 类比：像Photoshop里的图层，单独滚动的
- 绘制：对每一层，引擎会调用平台相关的图形库（Skia/2D Canvas），生成一系列绘制指令（如“画一个红色矩形”、“在此位置绘制文本”）。
- 这还不是像素，而是操作指令列表（类似
SkCanvas::drawRect(...)）。
- 这还不是像素，而是操作指令列表（类似
栅格化与合成：最终输出到屏幕
- 栅格化：将绘制指令列表真正转换为像素（位图），这一步通常由GPU进程或GPU加速完成（使用纹理）。
- 合成：将所有已栅格化的图层（位图），按照它们的层叠顺序、位置偏移、透明度、变换（transform）等，合并成一张最终的屏幕位图。
- 交给GPU：合成后的图像通过GPU渲染管道,最终显示在屏幕上。
关键技术点（面试和深度理解必问）
重排（Reflow） vs 重绘（Repaint） vs 合成（Composite）
- 重排：改变元素的几何形状（
width,height,margin,padding,position等）→ 需要重新走布局→绘制→栅格化→合成。最昂贵。 - 重绘：改变外观但不变几何形状（
color,background-color等）→ 跳过布局，直接从绘制开始。中等成本。 - 合成：只触发布局树的分层属性（
transform,opacity,will-change）→ 只进行合成操作，性能最好（通常由GPU完成）。现代动画优化的核心。
关键渲染路径
- 阻塞渲染的资源：CSS（阻塞渲染，但默认不阻塞DOM解析）、JS（阻塞DOM解析和渲染）。
- 非阻塞资源：图片、字体、
<script defer>、<script async>。 - 优化目标：尽可能早地发送首屏所需的CSS（放在
<head>）和关键JS,并延迟非关键资源。
合成器的威力
- 硬件事物层：
transform: translateZ(0)或will-change: transform会强制元素提升为独立层，GPU可以独立处理该层的变换，不触发重排和重绘,这是实现60fps流畅滚动和动画的核心。
“增量”与“脏位”标记
- 引擎不会每次DOM变化都重新全量跑流水线，它使用脏位（dirty bit）标记哪些节点需要重新布局或重绘，比如只修改了一个
<div>的宽度，引擎会标记该节点及其祖先节点为“脏”，并只重排受影响的部分（增量布局）。
如何实际剖析一个浏览器引擎？
如果你想深入代码或调试层面剖析：
- 选择引擎：Blink（Chrome/Edge/Opera，开源）或 WebKit（Safari，开源），Gecko（Firefox）也是好选择。
- 查看源码入口：
- Blink：
third_party/blink/renderer/core/包含dom/,css/,layout/,paint/,page/等核心目录。 - WebKit：
Source/WebCore/类似结构。
- Blink：
- 使用内部调试工具：
- 在Chrome地址栏输入
chrome://tracing/可以录制渲染流水线的详细事件。 - 在Chrome地址栏输入
chrome://inspect/+chrome://gpu/查看GPU加速情况、图层组成。
- 在Chrome地址栏输入
- 追踪关键函数：
- 解析入口：
HTMLDocumentParser::pumpTokenizer(),CSSParserImpl::parseStyleSheet() - 布局入口：
LayoutBox::layout(),FrameView::layout() - 绘制入口：
PaintController::commitNewDisplayItems() - 分层入口：
PaintLayerCompositor::updateIfNeeded() - 合成入口：
cc::LayerTreeHostImpl::PrepareTiles(),cc::TileManager::ScheduleTasks()
- 解析入口：
总结一句话：
浏览器引擎的剖析 = 理解“从字节码到像素”的流水线，核心在于解析（DOM/CSSOM）、计算（样式/布局）、生成（指令/位图）、组合（合成/GPU），并深刻理解”重排/重绘/合成“的性能代价差异。
希望这个框架能帮你更系统地理解浏览器引擎，如果想深入某个特定流程（如Layout计算、JS引擎优化、合成原理）,可以继续追问。
标签： 渲染引擎