有序数组去重：双指针原地操作背后的算法思维与工程实践
2026/9/7 18:46:50
1. 从输入到像素：渲染管线到底在做什么
作为一个常年跟 Chrome 渲染性能打交道的人，我经常被问到同一个问题：浏览器打开一个网页，从地址栏敲下回车到屏幕上出现画面，中间到底发生了什么？很多人会背出“解析 HTML、生成 DOM、计算样式、布局、绘制”这几个词，但真要往深了问，比如“为什么要分这么多层”“GPU 到底参与了哪些环节”“合成器是怎么把几万个图层拼成一帧画面的”，很多人就开始含糊了。
这篇文章我想用“像素的生命之旅”这个视角，把 Chrome 渲染管线的完整架构拆开来讲。说白了，你屏幕上每一个发光的像素，都不是平白无故出现的，它经历了从网络字节流到内存对象、再到 GPU 显存里的一张张纹理、最后被扫描输出到显示器的漫长旅程。理解这条链路，不仅是做前端性能优化的基本功，也是排查白屏、卡顿、掉帧、内存暴涨这类问题的唯一正确路径。
这套架构不光是 Chrome 在用，市面上主流的 Chromium 内核浏览器（Edge、Opera、Brave、国产各种套壳浏览器）基本都沿用了同一套设计。所以这篇文章适合以下几类人：被页面性能问题折磨的前端工程师、想搞懂浏览器原理的客户端开发、以及所有对“计算机图形显示”底层机制感兴趣的开发者。我会尽量用从业者之间聊天的口吻，不堆术语，但该讲的原理一个都不会少。
在正式开始之前，先说一个我对这套架构的整体判断：Chrome 渲染管线最核心的设计哲学，就是“能拆就拆，能并行就并行”。它把整个渲染过程拆成若干独立阶段，每个阶段可以独立执行、独立缓存、独立失效，然后通过一个高度异步的调度系统把这些阶段串起来。这种架构的代价是复杂度极高，好处则是性能上限极高——它能在 16.6 毫秒内完成一个 4K 屏幕、几十万个 DOM 节点、几百个图层的一整帧渲染。我们今天聊的，就是这台精密的“像素工厂”到底是怎么运转的。
2. 渲染管线全景图：五个阶段一场接力赛
在讲细节之前，我习惯先把整条链路画在脑子里。Chrome 渲染管线大致可以分成五个大阶段，分别是：DOM 构建、样式计算、布局、绘制、合成。这五个阶段不是简单的时间先后关系，它们之间有复杂的依赖和触发条件，但在宏观视角下，一帧新画面的产生，确实就是这五个阶段按顺序跑完的结果。
为了让你好记，我经常用“做菜”来打比方。服务端返回的 HTML 字符串是“菜谱”，CSS 是“调味规则”，浏览器要先把菜谱里的原料一个个摘出来清洗干净，这就是 DOM 构建；然后按照调味规则决定每样食材最终的味道和卖相，这是样式计算；接着把它们摆到盘子里，确定每个菜的位置和尺寸，这是布局；再然后给每道菜拍照，记录下每个像素的颜色，这是绘制；最后所有照片汇总成一张完整的餐桌照片，在你的屏幕上呈献给眼睛，这是合成。
这个类比虽然粗糙，但抓住了本质：渲染管线本质上是一条“从文本到像素”的单向流水线。你输入的是 HTML、CSS、JavaScript 执行后修改的 DOM 状态，输出的是屏幕上一个个具体的颜色值。中间每一步都会产生一种可以被下一阶段消费的“中间产物”。
还有一个很多人都忽略的关键点：这套管线并不是从零开始跑完一整个网页的所有元素，然后才显示第一帧的。Chrome 是增量式的、分块的、按优先级调度的。它可能先渲染首屏可见区域，再渲染滚动区域之外的懒加载内容；样式改了可能只重算一部分节点；滚动时可能只需要新增几个图层的光栅化结果。所以“渲染”不是一个一次性事件，而是一套持续运转的增量处理流程。理解这一点，才能看懂为什么 DevTools 里的 Performance 面板会出现那么多任务、微任务、长任务。
下面这张表是我整理的五个阶段的核心输入、输出以及各自的“产物特征”，方便你把全文的主线先抓住：
| 阶段 | 核心输入 | 核心输出 | 产物特征 |
|---|---|---|---|
| DOM 构建 | HTML 字节流 | DOM 树（节点树） | 与 HTML 层级结构一一对应 |
| 样式计算 | DOM 树 + CSS 规则 | 带有计算后样式的渲染树节点 | 每个节点有完整的 computed style 键值对 |
| 布局 | 样式化后的节点树 | 布局树（Layout Object Tree） | 每个元素有确定的几何位置和尺寸 |
| 绘制 | 布局树 + 绘制指令 | Paint Chunks / 显示列表 | 描述“画什么、按什么顺序画”的指令序列 |
| 合成 | 图层树 + 光栅化生成的位图 | 最终呈现在屏幕上的 Quad | GPU 纹理的排列组合 |
这里有个容易混淆的概念，很多人以为“渲染树”是浏览器实际存在的对象，其实在现代 Chrome 里，它已经被拆散成多个更细粒度的结构了，比如 LayoutObject、PaintLayer、GraphicsLayer 等。后面讲到合成阶段的时候，你会看到这棵“树”其实长成了好几棵相互关联的树，这也是 Chrome 为了性能不断演进的结果。
3. 核心阶段拆解：每一个环节都藏着性能密码
3.1 DOM 构建：从字节流到节点树，比你想象的更讲究
网络层拿到的 HTML 从本质上说就是一个字节流。字节流先经过解码器，按照 HTTP 头里声明的字符编码转成 Unicode 字符串。这一步听着简单，但坑不少，比如没有声明 charset 或者声明错误时，浏览器还要靠启发式猜测编码，猜错了就是满屏乱码。
字符串接下来进入词法分析器，把 HTML 文本切成一串 token，比如StartTag(div)、Attribute(id="app")、EndTag(div)这种。然后语法分析器根据这些 token 构建 DOM 树。Chrome 25 之后的 HTML 解析器是基于 C++ 实现的，遵循 WHATWG HTML 规范里的“解析算法”状态机，这个状态机的复杂程度不亚于任何一门编程语言的关键词解析器。
但从架构层面来看，真正值得你注意的是两个设计：
第一，HTML 解析器不是等完整地拿到全部 HTML 才开始建树的。它是边接收边解析边构建的。网络层每推过来一块数据，解析器就立即处理，争取尽早把首屏可用的 DOM 建立起来。这个过程叫做“渐进式解析”。也正因为是流式的，解析器遇到<script>标签时会根据规则决定要不要暂停 DOM 构建，先同步加载并执行脚本，因为脚本可能用document.write往文档里写入新的 HTML，这会改变解析器的输入流。这个设计现在被defer、async、module等加载策略优化了很多，但核心逻辑依然成立。
第二，DOM 构建过程中还有一个隐藏的“预扫描”机制。主解析器忙于构建 DOM 的同时，Chrome 会启动一个轻量级的预扫描器（HTML Preload Scanner），快速扫描后续的字节流，提前发现<img>、<link>、<script>等资源引用，然后立即发起网络请求。这就是为什么有些资源在 HTML 还没解析到那个位置时就已经开始下载了。我见过很多做性能优化的人只关注网络层的 HTTP 缓存、CDN，却忽略了预扫描器的工作方式——如果你在<head>里放了一个需要 CSS 前提的脚本，预扫描器可能也会提前把它下载下来，造成不必要的带宽抢占。所以该用loading="lazy"的资源还是要懒加载，该把脚本放后面的还是要尽量放后面，这都是在配合预扫描器的工作节奏。
3.2 样式计算：CSS 规则是怎么匹配到每个节点的
DOM 树建好之后，下一步是计算每个元素最终应用了哪些样式。这一步包含两个子任务：一是收集所有 CSS 规则来源，包括外部样式表、<style>标签、内联 style 属性、以及浏览器自带的 UA 样式；二是把规则和 DOM 节点做匹配，并层叠计算出每个节点的最终样式。
样式计算的输出叫 computed style，它是一棵带有完整样式信息的节点树，每个节点上挂着成百上千个属性键值对。Chrome 里 computed style 是扁平化的，也就是每个节点最终都有一个确定的display、color、margin、width等等，不管这些属性是通过类选择器、ID 选择器、属性选择器还是任意一种方式匹配来的。
这里有一个很多前端忽略的性能要点：样式计算要做“规则匹配”。过去很长一段时间里，浏览器需要把每个 CSS 选择器与每个 DOM 节点进行匹配测试，复杂度近似于“选择器数量 × 节点数量”。现代 Chrome 做了大量优化，最核心的是把 CSS 规则建立索引，比如根据最右侧的选择器类型（类名、标签名、ID）分桶，匹配时直接利用 DOM 节点的标签、类名、ID 查找候选规则，命中后再逐级确认。这好比图书馆不再按书名一本本找，而是先按标签分类到对应书架，再在书架上精确取书。
不过就算有索引，写得烂的选择器依然会拖慢样式计算。比如通配符*规则会命中所有节点，虽然现代引擎不会真的为全量节点生成匹配记录，但它在某些极端场景下会增加候选规则集合的规模。再比如极长、层级很深的后代选择器body div.main .content ul li a，每次匹配都要沿着父子关系向上回溯校验。从我实际做性能优化的经验来看，规范的 BEM 类名、避免过度嵌套选择器，能实实在在减少样式计算耗时，尤其是在页面节点数超过一万的场景。
还要提一个概念：样式失效追踪。浏览器不会在每次状态变化时对所有节点重新计算样式。当一个 class 属性改变时，Chrome 会通过元素标志位判断哪些节点可能受影响，建立一个“脏集合”，然后在下一帧中只对该集合内的节点重新计算样式。这套基于“条件失效”的机制贯穿整个渲染管线：DOM 树变了，不一定所有布局都失效；布局树变了，不一定所有绘制指令都失效。理解这套失效机制，是理解渲染性能优化的钥匙，因为大多数最佳实践本质上是“告诉浏览器哪些东西没变，减少失效范围”。
3.3 布局：从“样式长什么样”到“盒子摆在哪”
样式计算完成后，每个元素都有了完整的 CSS 视觉信息，但这时候还不知道它的具体位置和尺寸。布局阶段的任务，就是根据这些样式和文档流规则，计算出每一个元素在页面坐标系里的几何信息。
Chrome 的布局树与 DOM 树不完全对应。一个 DOM 元素可能生成多个布局对象，例如行内元素会被拆成多个片段；而某些纯样式元素（比如display: contents的元素）则不会生成布局盒子。布局对象之间构成一棵 LayoutObject Tree，这棵树上的节点包含几何信息和与渲染相关的标志位。
布局算法是渲染管线中计算量最大、最复杂的部分。现代 CSS 有正常流、浮动、绝对定位、flex、grid、多列、表格等布局模式，每种模式都有独立的几何求解算法。Chrome 的布局引擎 Blink 用了很多抽象来统一这些算法，比如它会把布局分解为“计算 min-content / max-content 尺寸”“解决百分比尺寸”“执行主轴/交叉轴对齐”等多个子过程。从代码层面看，Blink 里有个经典的LayoutBlockFlow::layoutBlockChild之类的函数，就是处理块级子元素的排列。
作为一个性能优化向的开发者，我最常碰到的布局相关性能问题，是“布局抖动”。具体指 JavaScript 在同一个渲染帧内反复读取offsetWidth、getBoundingClientRect等强制同步布局方法，然后又修改样式，导致浏览器不得不反复执行布局。业界管这个叫 Forced Synchronous Layout（FSL），不过大家更喜欢叫 layout thrashing。举个例子：
for (let i = 0; i < elements.length; i++) { const width = elements[i].offsetWidth; // 读取布局 elements[i].style.width = width * 2 + 'px'; // 修改样式，下一帧需要重排 }这段代码在每次循环里都先读取强制刷新布局，再修改样式。虽然代码简单，但循环几百上千次后，浏览器会被迫在循环中反复执行布局计算，导致严重的卡顿。修复方法很简单：先批量读取所有几何信息，再批量写入样式。或者用requestAnimationFrame分帧处理，再或者直接使用基于 transform 的动画避免触碰布局属性。
3.4 绘制：每个像素的“作画指令”是如何生成的
布局完成后，浏览器知道每个元素的几何位置和尺寸，但它还不知道这些元素应该“画成什么样”。绘制阶段的任务，就是为每个元素生成一组“绘制指令”，告诉光栅化线程最终如何把像素画出来。
现代 Chrome 里的绘制阶段产物叫 PaintChunk，更底层是一棵显示列表（DisplayList）。你可以把它理解成一份画图指令表，上面记录着“用红色矩形填充这个区域”“在坐标 (100,50) 处画一个圆角矩形边框”“在这个区域裁剪并绘制一张图片”等操作。这些指令是平台无关的，具体执行时再交给光栅化线程翻译成平台相关的 DrawOp。
绘制阶段有几个特性值得注意：
第一，绘制是分层的。不是一棵整树直接画一张图，而是每个层（PaintLayer）都有自己独立的显示列表。层与层之间可能有遮挡、透明度、滤镜、剪裁等关系。比如一个设置了position: fixed、z-index: 999的元素很可能被提升为独立层，于是浏览器可以单独重绘它，而不必牵连背景画布。
第二，绘制指令是“按从后往前”的顺序排布的。也就是先画背景、再画文字、再画边框、再画覆盖在上面的内容，这个顺序遵循 CSS 绘画顺序表。所有元素在绘制阶段会被归入一个又一个 paint chunk，每个 chunk 内是一段连续的相同上下文绘制指令。比如所有属于同一个合成层的背景块会被合并成一个 chunk，这样可以减少光栅化线程的切换开销。
第三，绘制阶段本身通常不直接用 CPU 往屏幕上画，它只是生成指令。真正把指令变成像素的操作，发生在光栅化阶段。现在的 Chrome 倾向于使用 GPU 光栅化（GpuRasterization），把绘制指令发送到 GPU 进程，由 GPU 执行指令并生成位图纹理。
我在调性能时经常用 DevTools 的 “Paint flashing” 功能，它能高亮显示页面中正在被绘制的区域。如果你发现某个操作导致大片区域闪烁，说明绘制范围过大，很可能是没有合理分层导致的。通过主动提升独立的、经常变化的元素为合成层，可以显著减少页面重绘面积。
3.5 合成：为什么说它是现代浏览器的性能引擎王牌
合成是整个渲染管线的最后一环，也是 Chrome 能实现 60fps 滚动和动画的关键。在合成之前，其实已经生成了很多“层”的绘制指令。合成阶段的任务是：把这些层的光栅化结果（纹理位图）按照正确的顺序、裁剪、变换，组合成一帧完整的画面，提交给系统显示。
要理解合成，必须理解“层”的概念。Blink 里有两层意义上的“层”：PaintLayer 和 GraphicsLayer（也叫合成层、CompositedLayer）。
PaintLayer 是视觉层，由 DOM 里具备某些条件的元素形成，比如根元素、设置了定位且 z-index 非 auto 的元素、有透明度的元素、有滤镜的元素、有overflow裁剪的元素等。PaintLayer 是渲染内部组织绘制顺序的单位，但它不直接对应 GPU 纹理。
GraphicsLayer 是合成层，是真正能够被独立光栅化、作为一张纹理上传到 GPU 的层。什么元素会变成合成层？最典型的是设置will-change: transform、transform: translateZ(0)、position: fixed，或者元素包含视频/Canvas/WebGL 等特殊内容。合成层越多，GPU 内存占用越高，但好处是，如果一个合成层的内容本身没有变化，只是它的位置发生移动（比如滚动、动画），那么浏览器不需要重新绘制和光栅化它，只需要在合成阶段改变它的位置矩阵，让 GPU 做一次简单的变换合成即可。
这就是 transform 动画性能远远好于 top/left 动画的根本原因。top和left的变化会触发布局和重绘，而transform的变化绕过了布局和绘制，直接触发合成。对现代浏览器而言，凡是能用 transform 实现的动画，就绝不要用 top/left。
合成阶段还有一个重要概念：图层树（LayerTree）。它不是简单地把所有 GraphicsLayer 平铺，而是组织成一棵树，节点之间包含父子级遮挡关系，同一个父层下的子层如果有溢出、嵌套裁剪，也会在树里表达。最终，合成器遍历图层树，把每个节点的内容按照 transform、opacity、clip-path 等属性进行变换，生成一个个 DrawQuad，再把这些 DrawQuad 提交给系统的显示合成器（Display Compositor）输出到屏幕。
整个过程中，用户看到的滚动其实是合成线程在处理的。当我们滚动一个页面时，合成线程只负责更新图层的位置矩阵和可见区域，并不需要通知主线程。这就是“async scrolling”（异步滚动）的原理。除非页面有scroll监听器或者touchstart监听器触发了主线程操作，否则滚动可以流畅地保持在 60fps 甚至 120fps。
4. 工具选型与调试实操：如何把渲染管线握在自己手里
理论再多，不落地都是空中楼阁。我做渲染性能分析时，几乎离不开 Chrome DevTools 的 Performance、Rendering、Layers 这三个面板。它们把上面讲到的每个阶段都变成了可视化图表，一旦你掌握它们，排查页面卡顿问题就不再是瞎猜。
4.1 Performance 面板：一张图看清每个阶段耗时
Performance 面板录制一段交互后，你会看到一个火焰图。火焰图上的每个长条代表一个任务，任务内部堆叠着若干函数调用。对我而言，最重要的不是看某项函数被调用了多少次，而是看主线程上哪些任务的耗时长时间超过了 16.6ms。如果出现大量长任务（Long Tasks），页面自然会出现掉帧。
录制前建议做这几件事：把页面滚动到需要分析的场景，关掉浏览器扩展以减少噪声，开启 CPU 降速模拟（比如 4x slowdown）以便放大性能问题。录制过程中要执行真实的用户操作，比如滚动、点击、输入，不要只干等。录制结束后，重点看 “Summary” 面板上的色块分布：蓝色是加载，黄色是脚本，紫色是样式和布局，绿色是绘制。如果紫色和绿色块占比异常高，说明你的页面在渲染阶段花费了太多时间，要从 CSS 选择器、布局策略、合成层数等方向找原因。
我见过很多人只看火焰图顶部的 Task 名称，然后用 “Self Time” 排序，但真正高效的定位方式，是先看每个长任务的调用栈里最底层的 Blink 内部函数。比如你看到Layout、UpdateLayoutTree、Paint这些关键词，再去对应的 DevTools 源代码区域跳转，能更快定位到是哪个操作触发了大量重排或重绘。
4.2 Rendering 面板：4个开关解决80%的排查需求
在 DevTools 的 Rendering 面板里（按 F1 或点击右上角齿轮，找到 Rendering），有几个功能我几乎每次都要用：
第一是 “Paint flashing”。打开后，页面中每次发生绘制区域的矩形块会闪烁绿色。如果滚动页面时整屏都在闪烁，说明你的滚动没有走纯粹的合成路径，背景或某个大容器被标记为需要重绘，通常是因为它们没有被提升为合成层。
第二是 “Layer borders”。打开后，每个合成层都会显示一个橙色边框，你可以直观看到页面上有多少个合成层，以及哪些元素被意外提升成了合成层。这个开关对排查“GPU 内存暴涨”特别有用。我见过一个页面加载后生成了 300 多个合成层，原因就是团队为了优化动画，给所有卡片都加了transform: translateZ(0)，结果 GPU 内存直接翻了十几倍。用这个开关一眼就能发现。
第三是 “FPS meter”。在滚动或者运行动画时，实测帧率。配合 Performance 面板可以判断帧率下降是主线程的脚本/布局耗时导致的，还是 GPU 合成遇到了瓶颈。
第四是 “Scrolling performance issues”。它会直接列出可能影响滚动的监听器，比如主线程 touch 事件、scroll 事件，并提示你哪些元素绑定了非 pass 模式的监听器。虽然最新版的 Chrome 已经默认在wheel和touchstart事件里做了 coalescing，但监听器仍可能导致无法走纯合成滚动。
4.3 Layers 面板：3D视图里看清层之间的“因果”
旧版的 DevTools 有一个实验性的 Layers 面板，能看到合成层的 3D 透视视图，可以直观检查每个层是否被渲染成立体堆叠。新版 Chrome 里这个面板有时候被默认隐藏，需要到实验设置里开启。它的价值在于可以验证某些元素是否真的被提升成独立合成层，以及层的裁剪关系是否符合你的预期。
例如，你期望为某个固定定位的弹窗创建独立合成层，但在 Layers 面板里发现它依然被合并进了父层，那就需要检查是否因为父层设置了overflow: hidden且子元素没有开启独立的will-change，导致浏览器把它裁进了父层的光栅化纹理里。这种情况下，弹窗的滚动性能就会大打折扣。
4.4 一行命令查看合成层列表
除了图形化界面，你也可以在 Performance 面板录制结束后，在 “Layers” 标签下看到每个图层的大小、内存占用、合成原因。或者用 Chrome 的chrome://tracing（新版迁移到了chrome://tracing或 DevTools 的 Performance Monitor），但对我来说太深奥的 trace 日常用得不多，大多数实际问题用 Performance + Rendering 面板就足够定位了。
5. 实战中的性能优化：三个真实场景的调优心得
5.1 场景一：页面滚动掉帧严重
先说一个我接手过的案例。一个商品列表页，每个商品卡片都有 hover 阴影效果和图片懒加载。用户反馈滚动时明显卡顿。我用 Performance 面板录制滚动过程后发现，主线程上每帧都有超过 8ms 的UpdateLayoutTree和Paint，而且滚动没有进入“异步滚动”状态。
进一步检查发现：每个卡片在 hover 时修改了box-shadow，这本来可以通过合成器动画实现，但实际代码用的是:hover中的box-shadow: 0 8px 30px ...，并且没有添加will-change: box-shadow。浏览器无法只靠合成器处理 box-shadow 变化，于是每次 hover 都会触发整个卡片的 paint。把阴影改为预先用一个伪元素做opacity渐隐渐显，并将伪元素提升为合成层后，滚动恢复顺滑。
这就是典型的“绘制优化”问题：把高频变化的视觉效果从绘制阶段移到合成阶段。同样的策略适用于背景颜色变化、边框变化等。你能用opacity和transform模拟的视觉效果，就尽量别改颜色和盒模型属性。
5.2 场景二：无限滚动列表，DOM 越来越多导致卡顿
另一个常见问题是无限滚动加载大量 DOM。用户一直往下滚，列表容器里的节点越来越多，最终布局计算和绘制范围越来越大。
我习惯的做法是：把可见区域之外的元素在滚动结束后从 DOM 中移除，或至少把它们的display设为none并移动到容器末尾。如果不想手动处理，可以给列表项设置content-visibility: auto。这是一个非常实用的 CSS 属性，它让浏览器跳过屏幕外内容的渲染，包括布局和绘制。实测下来，一个 5000 条数据的列表，只要每条设置了content-visibility: auto; contain-intrinsic-size: 200px;，滚动性能和页面初始加载都能有质的飞跃。
但要注意：content-visibility: auto需要设置contain-intrinsic-size，否则元素在进入视口前没有占位尺寸，滚动条高度会跳动，体验反而更差。这是我踩过的一个坑，后来查了文档才明白，这个属性本质上是通过contain机制让离线内容不参与布局，但它必须要有一个预估尺寸来保持滚动条稳定。
5.3 场景三：首屏白屏时间长
首屏白屏不一定完全是渲染管线的问题，很多时候是网络和脚本执行阻塞了首次渲染。但在渲染管线层面，有一个经常被忽视的优化点：减少不必要的图层提升。
我见过一个首屏卡顿的项目，页面在加载阶段创建了 200 多个合成层，每个层都要进行光栅化并上传到 GPU，导致 GPU 进程满负荷运转。最后检查发现，是 UI 框架给所有组件的根节点都加上了transform: translateZ(0)来开启硬件加速。这种“全量提升”在现代浏览器里已经没有必要，甚至有害。正确的做法是只给确实需要独立动效的元素提升层，而且优先使用will-change而不是transform: translateZ(0)，因为will-change只是提示浏览器提前准备，而后者会强制创建层。
另一个首屏优化点：避免在首屏 JavaScript 中强制同步读取布局。很多第三方脚本喜欢在页面初始化时靠getBoundingClientRect和offsetHeight来判断视口尺寸，这会让浏览器无法进行渐进式渲染。如果能把这些读取延迟到requestAnimationFrame前的微任务里，或直接使用视口单位vh/vw和 CSS media query，就能显著减少首次渲染前的阻塞。
6. 常见问题与排查技巧实录
我整理了一份我自己反复遇到的渲染管线相关问题速查表，把问题现象、可能原因、推荐排查工具和解决思路写在一起，希望对你有用。
| 问题现象 | 可能原因 | 排查工具 | 解决方向 |
|---|---|---|---|
| 滚动卡顿，fps 低于 50 | 主线程长任务，布局/绘制频繁触发 | Performance 火焰图，Rendering 面板 FPS meter | 减少重排重绘，改用 transform/opacity 动画，避免同步布局读取 |
| 动画掉帧，但主线程压力不大 | 合成层过多，GPU 光栅化/上传瓶颈 | Layers 面板，Chrome 任务管理器看 GPU 内存 | 合并合成层，降低过多样式提升，合理使用 will-change |
| 页面滚动时大面积绿色闪烁 | 背景或固定元素没有独立成层 | Paint flashing | 给大背景添加will-change: transform或translateZ(0)提升层 |
| 无限滚动列表越来越卡 | 屏幕外 DOM 过多，布局和绘制开销持续增长 | Performance 检查布局耗时趋势 | 虚拟滚动，content-visibility: auto+contain-intrinsic-size |
| 首屏白屏时间长 | 资源阻塞 + 图层过多 + 同步 JS 读取布局 | Performance 的加载阶段记录，Lighthouse | 减少阻塞脚本，延迟非关键资源，避免全量图层提升 |
| GPU 内存暴涨，页面崩溃 | 合成层无限增长，可能是will-change滥用 | 任务管理器里的 GPU 内存列，Layer borders | 移除不必要的 will-change，用后释放层，动画结束后移除提升 |
最后再分享一个我自己的“土办法”：排查掉帧问题时，我习惯先在页面开着 FPS meter 的情况下，用键盘快速滚动页面，观察帧数最低点大概出现在哪个区域，然后滚动到那个区域用 Performance 录制一段 5 秒的滚动，定位到具体的长任务。这个流程比一上来就看火焰图要快得多。
7. 渲染架构建模的深层思考：为什么它如此设计
看到这里，你可能会好奇：Chrome 为什么不直接用一个更简单的流程，比如解析完整个页面再一次性画到屏幕上？何必搞出 DOM、样式、布局、绘制、合成这么多层？这背后其实是工程上对“增量更新”和“交互响应性”的极度追求。
试想一下，如果整个页面是一张巨大的位图，那任何局部变化都得重绘全图，这在动辄几十上百兆像素的屏幕上是不可能的。所以 Chrome 把一个页面从结构上拆成了树，从空间上拆成了层，从时间上拆成了多个可以独立缓存和失效的处理单元。每一帧只处理“脏”的部分，绝大部分渲染产物可以跨帧复用。
合成器的存在更是为“动画友好”而生的。UI 动画里最常用的是位移、缩放、旋转、透明度，这些都不改变元素的绘制结果，只改变它的呈现方式。合成器可以让 GPU 以极低的成本在每帧执行矩阵变换，接近零主线程开销。可以说，整个渲染管线的后半段，都是为了给动画和滚动这样的高频交互让路。
还有一个容易被忽略的设计是“进程/线程隔离”。现代 Chrome 里，解析 HTML、执行 JS、计算样式、布局、绘制这些主线程工作都在渲染进程的主线程上完成；而图层光栅化通常发生在光栅化线程；合成又交给专门的合成线程；最终提交给 GPU 进程。线程之间通过命令列表和回调进行异步通信。这样做的好处是，即使主线程被某个复杂脚本阻塞，画面依然保持可滚动、可响应，因为合成线程已经持有最新一帧的纹理。这正是我们日常感知到的“主线程卡顿但页面还能滚动”的根本原因。
所以说，渲染管线的完整架构，本质上是一套为了达到“高效增量更新”和“高响应性”而设计的复杂分布式处理系统。我们在每个阶段做的性能优化，其实都是在帮助这套系统节流：让该失效的失效，让不该失效的不失效；让该合层的合层，让不该合层的不合层。
我个人在实际操作中的最大体会是：千万不要把渲染管线的五个阶段当成永远等量齐观的流程去逐一优化。不同页面、不同交互，瓶颈出现的阶段完全不同。有的页面瓶颈在 JavaScript 导致的样式重算，有的在布局复杂度，有的在绘制范围，有的在合成层数量。比“跑一遍优化清单”更重要的是先定位瓶颈在哪个阶段。只要你能熟练使用 Performance、Rendering、Layers 这三个面板，再对照本文的管线拆解，遇到任何渲染性能问题，都能像老手一样快速找到那条最关键的链路。