浏览器架构与渲染原理：从多进程到合成层的性能优化指南

有一次，一个同事拿着刚写完的页面来找我，说滚动起来特别卡。我看了一眼代码，他用 left 属性做了一个跑马灯效果，元素一多就掉帧。我说这个问题不在代码层面，在浏览器渲染层面。他愣住：“前端还要懂渲染？”我说，如果你不知道浏览器是分进程跑的、不知道一帧画面是怎么从 HTML 合成出来的，那你排查卡顿就只能靠猜。这个场景，几乎是我这几年带人时最常遇到的对话。

后来我越来越觉得，浏览器不只是一个“显示网页的框”，它是一套高度复杂的系统。只要你能把架构、渲染、调试和 API 这四件事串起来，很多前端疑难杂症都会从“玄学”变成“可解释的工程问题”。这篇文章就想认真聊聊这四块，不是丢一堆术语，而是尽量把底层逻辑讲清楚，再给一些能直接用的实操建议。无论你是刚入门的前端，还是写了好几年业务代码的老司机，这几块东西都值得在某个阶段重新回头看一遍。

1. 浏览器拿的是多进程架构：稳定性、安全性和你看到的一堆“谷歌浏览器进程”

1.1 为什么浏览器需要拆分进程

浏览器最早是单进程的，所有标签页、插件、渲染逻辑全挤在一个进程里。那个年代随便一个页面崩溃，整个浏览器全部白屏；一个恶意插件，能直接读到整台机器的文件。后来 Chrome 率先转向多进程架构，把不同职责拆进独立进程，相互之间通过进程间通信（IPC）协调。现在的 Chromium 体系里，一个开着十几个标签页的浏览器，任务管理器里通常能看到几十个进程，这是正常现象，不是什么“病毒”。

先记住这张分工表：

这里最值得说的是“Site Isolation”（站点隔离）。从 Chrome 67 开始，浏览器默认把不同站点放进不同的渲染进程，跨站 iframe 甚至会被单独隔离到独立进程。这么做的原因很直接：安全性。如果一个恶意页面和你打开的银行页面共用同一个渲染进程，它就能通过进程内漏洞读到你的 DOM。拆开后，哪怕触发漏洞，拿到的也只是一个被沙箱困住的空壳进程。

1.2 多进程带来的收益和代价

多进程架构的收益有二：一是隔离，一个标签页崩了不影响整个浏览器；二是权限控制，渲染进程在沙箱里运行，没有操作系统级别的文件访问权限，想干坏事也得先突破沙箱。代价也很明显——内存占用高。每个渲染进程都有自己的 V8 堆和渲染状态，开上百个标签页时内存会特别紧张。这也是为什么用久了会感觉浏览器“越用越卡”，本质是重复的进程资源和内存碎片在累积。

如果你负责的是一个复杂的前端应用，理解多进程对你的实际价值是什么？至少有三点：

• 排查问题时先分清是“渲染进程问题”还是“主进程问题”。页面无响应但浏览器还能拖动窗口，大概率渲染进程卡死。窗口整个动不了，才要考虑主进程。
• 在代码里避免无意义的跨站点 iframe。每多一个跨域 iframe，浏览器可能额外启动一个渲染进程，内存会明显上涨。
• 遇到页面崩溃，先去看任务管理器和 chrome://process-internals，能看到崩溃的是哪个进程、什么原因，比你在代码里瞎猜高效得多。

有时候我会把浏览器架构中的进程拆分类比成后端的微服务架构：单体应用部署简单但一个服务挂了全站瘫；微服务拆分后各自独立、容错更好，但服务间通信和运维成本上来了。浏览器也是这样，用“进程隔离”换稳定性，用“IPC 通信”换功能协作。理解了这层取舍，你对分布式架构和浏览器架构的认知其实是同一套思维模型。

2. 渲染流水线：从 HTML 字节流到显示器上的像素，中间发生了什么

2.1 解析阶段：DOM、CSSOM 与脚本阻塞

在地址栏输入 URL 回车之后，网络进程先发起请求，拿到响应后把字节流交给渲染进程。这个阶段很多人只大概知道“浏览器要解析 HTML”，但它不是一个简单的字符串处理过程。字节流首先根据编码格式（charset）解码成字符，然后做分词（tokenization），再按照 HTML 状态机构建出 DOM 树。与此同时，HTML 解析器还会运行一个预扫描器（Preload Scanner），提前发现页面里的图片、样式表、脚本请求，推给网络进程并发加载，而不是等解析到那个标签才发起请求。首屏性能的很大一部分，其实是在这个预加载阶段抢回来的。

样式部分会单独构建 CSSOM（CSS Object Model）。CSS 解析看起来只是把选择器和声明变成规则列表，但它的开销往往被忽略：遇到 div .a .b .c 这种嵌套很深的选择器，匹配代价会上升；页面里几十个样式表，每一次匹配都要参与计算。这也是为什么现代前端都愿意用 CSS Modules 或原子化 CSS，本质上是在压缩匹配复杂度。

脚本对解析的影响就更经典了。默认情况下，遇到 <script> 会阻塞 DOM 构建，因为脚本可能用 document.write 改 DOM。defer 让脚本在文档解析完成后按顺序执行，async 让脚本下载完就执行、不保序。如果你想知道这个页面为什么首屏慢，第一步就是去看是不是有一堆没标 async/defer 的外部脚本把 HTML 解析堵死了。

2.2 样式计算、布局（Layout）和分层

DOM 和 CSSOM 准备好后，浏览器会做样式计算（Style Recalc），把每个 DOM 节点匹配到的所有 CSS 规则合并成最终的 computedStyle。这一步完成后，进入布局阶段。布局会计算每个元素在页面上的几何位置和尺寸。传统上这是最耗时的步骤之一，所以 Chromium 重写了布局引擎，叫 LayoutNG。但无论引擎怎么优化，布局都是“一发动全身”的操作：修改某个节点的宽度，可能导致它父级、兄弟节点甚至整棵子树重新布局。

这里要再说一个很多人混淆的概念：回流（reflow）和重绘（repaint）不是一回事。

• 回流是指几何属性变化后重新计算布局，比如改 width、left、top、font-size。
• 重绘是几何没变但外观变了，比如改 color、background，只重新执行绘制指令。
• 合成（composite）则是在合成层组合位图，它是最廉价的操作。

所以性能优化的底层原则就是：能触发合成的，就别触发重绘；能触发重绘的，就别触发回流。你在实践中会看到大量“使用 transform 替代 left”的建议，不是因为它听起来高端，而是因为 transform 只影响合成层，不触发布局和绘制，浏览器可以把动画整帧交给 GPU 处理。跑马灯卡顿的问题，恰恰就是用了 left 反复触发回流。

2.3 绘制、光栅化与合成：GPU 在这条链路里的位置

布局完成后，浏览器并不是直接“画”到屏幕上。渲染进程先把每个元素的绘制操作记录成绘制指令（display items），再按层级拆分成多个图层（Layer）。一个拥有 transform: translateZ(0)、opacity 动画或 will-change 的元素，都可能被提升为独立合成层。合成器线程负责决定哪些图层可见、哪些需要更新，并把这些图层切成瓦片（tile），交给光栅线程（raster）转成位图纹理，最后上传到 GPU 进程做合成，输出成你看到的那一帧画面。

这个过程解释了为什么动画卡顿不能只看 JS 代码：如果你的页面生成了几百个合成层，每一帧 GPU 都要重新合成这些图层，内存和带宽会被迅速打满。所以在性能调试时要警惕“过度提升合成层”。很多前端容易走极端，为了流畅，什么元素都加 will-change，结果卡得更厉害。合成层是资源，不是万能药。

2.4 渲染引擎与 GPU 渲染：从 Blink 到 WebGPU，再到 Impeller 的启示

提到渲染，就必须聊渲染引擎。Chromium 用的 Blink，Firefox 用的 Gecko，Safari 用的 WebKit，它们都遵循类似流程：HTML 解析 → 样式计算 → 布局 → 绘制 → 合成。区别在于具体的算法和优化策略。比如 Firefox 的 Quantum CSS 引擎使用并行样式计算，多核 CPU 利用率更高；Safari 在苹果设备上深度调用了系统的渲染加速能力。

浏览器内的高性能图形渲染也不是只有 Canvas 2D 一条路。WebGL 基于 OpenGL ES，能直接操作 GPU 绘制复杂的 3D 场景；今天 WebGPU 已经逐渐普及，它给人最大的感受是更贴近现代图形 API 的设计，尤其是 compute shader 和更强的 GPU 控制权。如果你听到有人在讨论“OpenGL 能做球形渲染吗”，答案是能，但它在驱动层面的兼容性让人头疼，而 WebGPU 的设计让这类渲染更容易写出高性能的实现。

有意思的是，非浏览器领域的渲染引擎也在走同一方向。Flutter 的 Impeller 渲染引擎就是为了替换 Skia 而设计的，它绕过了传统图形 API 的高层封装，偏向于预编译 Shader、减少运行期编译卡顿，目标就是让一帧画面更稳定地由 GPU 光栅化出来。你仔细看，它的思路和浏览器合成架构非常像：尽量让工作发生在 GPU、尽量让渲染过程可预测。所以我说，理解浏览器的渲染流水线，以后学任何渲染相关的东西都会很快，因为它代表的是现代渲染系统的通用范式。

2.5 一个真实排查案例：样式计算时间过长导致滚动掉帧

分享一个我踩过比较典型的坑。某个管理系统页面，滚动时明显掉帧。我用 DevTools 的 Performance 面板录制了滚动操作，看到主线程每一帧里 Recalculate Style 占掉了将近 25ms。一帧总共只有约 16ms 预算，你光算样式就超了，其他任务全被挤出去。

根因是产品迭代了两年之后，全局样式表里有大量后代选择器嵌套，其中一个通用组件类被嵌套了七八层。每次滚动造成一个节点类名变化，浏览器都要重新匹配大量规则。修复方式很简单，把深层嵌套拍平，组件根节点用独立类名，加上 CSS 样式作用域隔离。改完再录 Performance，Recalculate Style 降到了 2ms 以下。这个案例不是为了说某种写法绝对正确，而是想强调：知道某一步在流水线里的成本级别，比背一百条优化口诀都有用。

3. 调试不只是打开 DevTools：一套能解决线上问题的调试方法论

3.1 DevTools 核心面板的高效用法

DevTools 每个人都会打开，但很多人只用 Console 和 Elements。真到排查性能问题时就抓瞎。我列几个我日常用最多的面板用法：

Sources 面板：不只是打断点，更重要的是条件断点、日志断点（logpoint）和表达式监视。遇到“这段代码里面那个变量有问题”时，条件断点能省下大量手动刷新时间。线上代码被压缩过、看不到变量名时，别急着骂工具，先看 sourcemap 是否正确映射，几乎所有“调试不到源码”的问题都出在 sourcemap 路径配置上。

Network 面板：看一个请求不能只看“完成时间”，要看 Waterfall 的每个阶段。Queueing 时间过长说明浏览器连接或优先级受限；Stalled 是等待空闲 socket；TTFB 长说明后端慢；Content Download 长说明资源本身太大或网络带宽吃紧。有一次客户说“接口有时候要好几秒”，我让他看 Waterfall，发现大部分时间耗在 Content Download，但文件只有 2KB，最后定位到那个接口在网关层被压缩策略拖慢了。你如果只看总耗时，永远定位不到具体环节。

Performance 面板：录制时尽量模拟真实操作，而不是清空缓存后点一下。录制完成后重点看主线程的 Task 颜色分布：黄色是 JS 执行、紫色是样式和布局、绿色是绘制。如果一帧里 JS 执行超过 50ms，说明主线程被长任务占满，交互自然卡。配合 Long Tasks 的标注，一眼能找到是哪段函数拖慢了帧率。

Memory 面板：做堆快照对比。先做一次操作前快照，再操作几次，跑垃圾回收，再做一次快照。对比 Retained Size 大的对象，基本能定位到是谁在持有未释放的引用。很多“内存涨上去就不降”的问题，本质上就是某个全局对象或事件监听一直持有着旧 DOM。

3.2 移动端和 WebView 的真机调试，别只会 alert

移动端页面的调试比桌面端麻烦，但方法其实是现成的。Android Chrome 浏览器可以通过 USB 连接，在电脑上的 chrome://inspect 里找到设备，直接打开 DevTools 调试。WebView 则要在代码里开启 setWebContentsDebuggingEnabled(true)，生产环境务必关掉它，不然任何连上你手机的人都能直接调试你的应用页面。

iOS 端的 Safari 也有类似方案：手机开关的“网页检查器”打开后，用 Mac 上的 Safari 开发者菜单连接真机调试。如果你在开发跨端 WebView，vConsole 和 Eruda 这类工具非常值得内置到测试包，它们能在移动端页面上展示 Console、Network 和 Cookie 信息。很多线上问题在 PC 上无法复现，但挂在手机上一定能看到具体报错。

设备调试这个思路其实可以延伸出去。我在做 IoT 项目时接触过串口调试助手、BLE 调试助手，还有底层常用的 GDB。前端开发者看到这些工具会觉得“这不是我们世界的东西”，本质上它们跟 DevTools 是同一类角色：在系统链路里找一个观察点，把中间状态暴露出来。浏览器里你通过 Performance 观察渲染流程；嵌入式开发通过调试器观察寄存器状态；BLE 调试助手看的是蓝牙协议栈的握手过程。工具不同，思维是通的。

3.3 用代码做监控：PerformanceObserver、PerformanceAPI 和日志上报

DevTools 适合开发和联调阶段，线上问题必须靠代码自己去抓。浏览器提供了 PerformanceObserver，可以监测长任务、布局偏移、LCP 等指标。举个例子，我自己在项目里加过这样一段代码：

javascript复制const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) {
      console.warn("检测到长任务：", entry.name, entry.duration);
      // 上报到监控平台
    }
  }
});
observer.observe({ entryTypes: ["longtask"] });

配合 Performance Timeline API 里的 performance.mark 和 performance.measure，可以精确测量某段业务逻辑的执行耗时。这些信息在用户挂机或卡顿无法复现时，比任何“我觉得这行代码没问题”都更有说服力。日常我也会用 web-vitals 库采集 CLS、LCP、FID，把这些指标和页面路由关联起来，这样每次发版后基本能快速判断性能是否回退。

3.4 线上问题排查链路：从“控制台报错”到“全过程回放”

很多人遇到线上问题只会盯着报错信息，比如“Cannot read properties of undefined”，然后去代码里找那个属性哪里可能为 undefined。这种排查方式效率极低。我现在遇到线上问题，会按这条链路走：

先看网络请求是否都返回了预期结果。很多时候报错是因为某个接口在低版本系统下返回了额外字段，导致数据结构对不上。再判断报错发生的环境和条件：浏览器版本、操作系统、登录用户、页面入口。接着用性能数据和日志定位执行到哪一行时才报错。最后如果还复现不了，我会在代码里加更细粒度的埋点，再让用户在测试环境复现，或者加载线上 sourcemap 后直接看堆栈。

有一次线上监控告警“渲染层错误 TypeError”，概率很低，错在一段对用户配置项做格式化处理的函数。排查了半天发现是部分老用户账号里的配置项是历史脏数据，类型是字符串而不是数组。代码逻辑本身对“合法数据”处理得很好，但对“脏数据”完全没有兜底。后来我们在所有外部数据入口统一加了 schema 校验和一层容错处理，这个问题再没出现过。这件事给我的启发是：线上的 bug 很多时候不是代码写错了，是数据比你想象的脏。

4. 实用 API 清单：哪些浏览器内置能力值得天天用

4.1 数据存储：localStorage、IndexedDB、Cache API，到底该怎么选

前端能用的存储方案很多，但选错代价很大。localStorage 只有同步读写、约 5-10MB 空间，适合存用户偏好这种小数据，不适合存大对象；它一同步读阻塞主线程，频繁读大 JSON 时会直接造成卡顿。sessionStorage 在标签页关闭后清空，适合存临时会话状态。

IndexedDB 事务型数据库，支持索引、游标、异步读写，容量大得多。现代浏览器 IndexedDB 的 API 已经被封装得容易接受，但每次手动写事务很琐碎。Dexie.js 和 idb 这类库能明显降低使用成本。做离线优先的应用时，IndexedDB 几乎是标配，比如把上次拉取的列表数据缓存到本地，下次启动先渲染旧数据再刷新新数据。

还有一套跟 Service Worker 配套的 Cache API。注意它设计出来是给请求/响应对象做缓存的，跟“把 JSON 存起来”是两种思路。PWA 离线时把 HTML、JS、CSS、图片放进 Cache Storage，配合 Service Worker 的事件拦截就能实现完整离线访问。这三者不冲突，反而经常配合用：Cache 管静态资源，IndexedDB 管业务数据，localStorage 管轻量配置。

4.2 观察类 API：IntersectionObserver、ResizeObserver、MutationObserver

滚动懒加载是老需求。早些年最普遍的做法是监听 scroll 事件，在回调里反复读取 getBoundingClientRect()，这一过程会在每次滚动时强制同步触发布局，性能极差。IntersectionObserver 是专门干这个的：由浏览器在元素进入视口或离开视口时异步回调，不阻塞主线程。我自己做无限滚动时都会用它，大概长这样：

html复制<div class="sentinel"></div>

javascript复制const sentinel = document.querySelector(".sentinel");
const observer = new IntersectionObserver((entries) => {
  if (entries[0].isIntersecting) {
    loadNextPage();
  }
});
observer.observe(sentinel);

ResizeObserver 则是监听元素尺寸变化，替代“窗口 resize + 手动 getBoundingClientRect”的旧方案。现在响应式图表、自适应容器里基本离不了。MutationObserver 用于监听 DOM 结构变化，但很容易被滥用。如果你发现自己在用它频繁监听一个高频变化的节点，先停下来想一下：是不是架构上就存在问题；这种方案会带来持续的观察开销，监听范围不要设得过大，回调里的操作也不要太重。我的原则是：这三个 API 能解决 90% 的“实时响应状态”需求，但不要为了酷去对长期运行的页面加无谓的观察器。

4.3 请求控制的细节：AbortController、统一拦截、sendBeacon

fetch 刚普及时大家只把它当更高级的 XHR，其实它的能力远超 XHR。一个常被忽略的是 AbortController，它能在用户离开页面或超时时主动取消请求。比如搜索框做实时查询，旧请求还没返回时新请求已经发出，就必须用 AbortController 取消旧请求，不然旧响应可能覆盖新结果。实例逻辑很简单：

javascript复制const controller = new AbortController();
setTimeout(() => controller.abort(), 5000);

fetch("/api/search", {
  signal: controller.signal,
})
  .then((res) => res.json())
  .catch((err) => {
    if (err.name === "AbortError") {
      console.log("请求已取消");
    }
  });

业务开发中我还会做一层统一的请求封装，把所有 fetch 都过一遍，统一处理 token 注入、错误码解析、401 跳转和取消逻辑。这样出现“为什么这里没带认证信息”这类问题，只需要看一个地方。

Navigator.sendBeacon() 是很多人埋点时会漏掉的 API。传统的 navigator.sendBeacon 不阻塞页面卸载、请求可靠度高，适合发送日志或埋点数据。它的特点是浏览器会在合适时机把请求发出去，不受页面跳转影响。如果你还在 beforeunload 事件里用同步 XHR 发日志，我建议立刻换掉，那种写法在移动端尤其不可靠。

4.4 权限、设备与协作类 API：从剪贴板到广播通知

现代浏览器的 API 边界已经扩展到系统和设备层面。Clipboard API 支持读写系统剪贴板，但要注意它受权限策略限制，大多数浏览器要求在用户手势（点击/按键）内调用。Notification API 需要用户显式授权，授权弹窗在桌面端体验还行，移动端很多浏览器会要求装成 PWA 或加到主屏幕后才允许推送，开发前建议先查好兼容性条件。

Web Worker 提供了独立于主线程的执行环境，可以把大量计算、图片处理、JSON 解析等任务丢到后台执行。它和 SharedWorker 的区别是，后者还能被多个标签页共享。BroadcastChannel 则是标签页之间互相发消息的轻量方案，比如用户在多标签页中登录一个系统，某个标签页执行了退出登录，其他标签页也能立刻收到消息并清掉本地状态。跨标签页状态同步这个问题，用 BroadcastChannel 比 localStorage 的 storage 事件更简单直接。

我自己实际项目里比较高频的组合是：IndexedDB 存业务数据缓存，BroadcastChannel 做多标签页同步，Service Worker 做离线资源处理和后台同步，再配合 Page Visibility API 在页面被切到后台时暂停耗时操作。这套组合基本可以支撑一个不错的“桌面级体验”的 Web 应用。

5. 高频翻车现场：API 调用与接口规范里的那些坑

5.1 隐私协议里没声明对应 scope，接口直接拒绝

我在接一个第三方能力时遇到过 chooseImage:fail api scope is not declared in the privacy agreement。报错字面意思是调用的 API 没有在隐私协议中声明。很多团队只关注代码是否写对，忽略了平台侧的权限声明流程。这类问题在小程序、部分 Web 生态里很常见：平台要求你在配置中心提前声明会使用哪些 scope，再在拉起用户授权前展示对应隐私说明。处理方式不复杂，补全隐私协议声明、重新走审核即可，但如果你不知道是这一层在卡你，可能要在代码里排查很久。

5.2 Token 和版本对不上，登录一直失败

另一个很常见但极易被忽略的问题是认证信息与后端版本不匹配。比如 login failed. check api token or gitlab version 这类报错，字面上把“token 错误”和“版本不匹配”并列，很多人在代码里一遍遍检查 token 设置没错，却忘了后端服务已经升级、接口协议发生了变化。老 token 的签名算法或格式不再被新版本接受，这是升级联调阶段最容易踩的坑。我的建议是，遇到认证报错先分三个层面排查：token 本身是否过期、签名算法/密钥是否匹配当前服务版本、请求头是否按新协议规范传递。别只盯着“身份过期”这一个可能。

5.3 模型输入太长，上下文长度直接超限

接入大模型 API 时，我已经不止一次看到这样的报错：this model's maximum context length is 1048576 tokens。很多人的第一反应是“我明明是几千字的输入，怎么会超限”，实际上是整个对话历史、系统提示、工具返回结果都被算进了 token。我曾经在一个项目里把整段历史对话原封不动地塞进请求，两个小时的对话积累下来很容易触顶。解法其实很朴素：把历史消息按时间切片，只保留最近的 N 轮；长文档分块索引，用到哪块检索哪块；用摘要替代完整历史。还有一次报了 the supported api model names are deepseek-v4-pro, deepseek-v4-flash...，原因是代码里写死了旧模型名，但 API 端已经升级，把入参模型名改成支持范围内的即可。这类问题核心是 SDK 版本和 API 服务版本没有保持同步。

5.4 自己设计的接口能不能少让前端踩坑

被人坑过之后，我自己设计接口时会特别注意一些规范。RESTful 风格里最基本的要求是：资源用名词，操作用 HTTP 动词，状态码要有语义。更实际的是这些自查项：

• 创建接口返回 201，还是所有成功都返回 200？统一最重要。
• 错误返回是否带机器可读的 code 字段？只有 message 的话前端要匹配文字，一改版前端就崩。
• 列表接口是否支持 page/pageSize 或游标分页？不分页的接口等到数据量上来，前端只能临时加前端分页，性能一塌糊涂。
• 变更类接口是否幂等？重复提交时后端能不能只处理一次？否则前端要做一堆防重处理。
• 字段命名是否统一 camelCase 或 snake_case？混合命名会让前端每层做转换，迟早出 bug。

这些不是多高深的技术，但一个接口文档如果这些地方写清楚了，前端联调效率至少提升一半。API 设计本质上是和未来的调用者（包括两个月后的你自己）沟通，规范和一致性就是沟通语言。

5.5 一张表记住 API 调用排查的基本思路

6. 最后分享几个常年管用的杂谈技巧

调试这件事做得多了，我慢慢发现，高手和新手的差距很多时候不在于知道的 API 多，而在于排查思路是否成体系。我在实际项目里形成了一套固定打法：拿到问题先分“进程层、渲染层、网络层、数据层”哪个环节出的问题。分开后，再去看对应的工具——进程问题看任务管理器，渲染问题记录 Performance，网络问题看 Waterfall，数据问题就把接口返回拿下来逐字段对比。这个方法帮我解决过很多看似诡异的 bug，也让我很少再靠“刷新一下试试”碰运气。

另外一个小技巧：如果你发现页面滚动卡顿，先别急着优化代码，打开 Performance 面板录一段滚动数据，看主线程每一帧的时间花在哪。如果你发现合成层数量多到难以置信，用 DevTools 的 Layers 面板看一眼有多少层、每层多大，往往能定位到意料之外的 will-change 或动画用法。如果你发现接口总在浏览器端报错，先把请求头、响应体、时间线三个阶段的数据各截一张图，很多时候问题根本不在前端代码。

浏览器这套东西，初学时觉得琐碎，但越用到后面越发现它是一套底层素养。今天浏览器已经不仅能打开文档，还能跑复杂的图形应用、调用系统设备、做离线存储和后台同步。把这套底层的架构和渲染逻辑吃透，你学任何新框架、新 API 的速度都会比别人快很多，因为你看到的不是一层 API 方法，而是它在一整条链路里处在什么位置、解决的是哪个环节的问题。