2025 年了，大家还在用 Chrome 吧？全球市场份额常年 65%+，不管是开发还是日常上网，几乎没人能离开它。
但你有没有想过：为什么 Chrome 可以同时开 100 个标签还不卡？为什么某个页面卡死或崩溃了，别的标签还能正常用？为什么 IE/Edge 老版本动不动就“浏览器无响应”，而 Chrome 几乎从不整页卡死？
答案就四个字：多进程架构。
今天我们把 Chrome 的底层进程模型扒得底朝天，顺便对比当年 IE 的单进程惨状，让你彻底明白 Chrome 为何能统治浏览器江湖十几年。
1. 打开 Chrome 那一刻，到底发生了什么？
你双击 Chrome 图标，操作系统首先启动的是一个主进程（Browser Process），这是整个浏览器的“大脑”，只有一个，拥有唯一的 PID。
这个主进程负责：
- 绘制浏览器界面（地址栏、书签栏、后退按钮等）
- 处理用户交互（点击、输入 URL、转发后退）
- 管理所有子进程的创建、销毁
- 提供存储功能（Cookie、LocalStorage、Cache 等）
- 协调网络请求、GPU 加速、本地文件访问等
主进程启动后，会立刻创建几个常驻子进程：
- GPU 进程（最多一个）
- 网络进程（Network Process，通常一个）
- 插件/扩展进程（每个扩展可能独立，也可能共享）
然后你输入 URL 回车，或者打开新标签，主进程才会为这个站点创建一个渲染进程（Renderer Process）。
这就是为什么你打开任务管理器（Shift + Esc），会看到一堆 “Google Chrome” 进程，而不是只有一个。
2. Chrome 的五大核心进程（2025 年最新架构）
截至 2025 年 12 月，Chrome（版本 130+）的标准进程模型如下：
-
浏览器主进程（Browser Process） × 1 全局老大，负责一切非页面渲染的事。
-
渲染进程（Renderer Process） × N（每个站点隔离组一个） 这是最重的进程，核心职责：把 HTML、CSS、JavaScript 变成你看到的页面。 内部包含：
- Blink 排版引擎（布局、样式计算）
- V8 JavaScript 引擎
- Skia 图形库
重要：从 Chrome 67 开始，默认开启 Site Isolation（站点隔离），同一个 Tab 内不同来源的 iframe 也会拆到不同渲染进程，彻底防御 Spectre/Meltdown 类侧信道攻击。
-
GPU 进程 × 1 负责所有 GPU 相关任务：UI 界面绘制、CSS 3D 动画、Canvas、WebGL、视频解码加速。 现在几乎所有页面都会用到 GPU 加速，哪怕只是一个 transition。
-
网络进程（Network Process） × 1 负责所有网络请求（HTTP/HTTPS/QUIC/H3），包括 DNS、TCP 连接、TLS 握手、缓存判断等。 独立出来后，主进程和渲染进程都不用自己处理网络，安全性更高。
-
插件/扩展进程（Plugin/Extension Process） 每个扩展默认独立进程（--process-per-site 策略下可能合并），Flash 早已死透，现在主要是扩展。
还有一些辅助进程：Utility Process（处理视频解码、音频处理）、PPAPI 插件进程等。
打开 Chrome 任务管理器你会看到：一个页面可能对应 6～10 个进程，很正常！
3. 为什么非要多进程？IE 的血泪教训
早年 Internet Explorer 6～9 是典型的单进程架构：
- 所有 Tab、插件、页面渲染全在一个进程里跑
- 一个页面卡死 → 整个浏览器卡死
- 一个页面崩溃 → 整个浏览器崩溃
- 一个恶意页面拿到渲染权限 → 能直接读你硬盘（当年 IE 漏洞多到哭）
2008 年 Chrome 横空出世，直接上多进程 + 沙箱（Sandbox）：
- 每个渲染进程都被严格沙箱限制，不能直接访问文件系统、网络、剪贴板
- 只能通过 IPC（Inter-Process Communication，进程间通信）向主进程申请权限
- 一个页面崩溃，最多死一个渲染进程，主进程立刻重建，别的标签丝毫不受影响
你有没有过这种体验：某个页面卡成 PPT，点右上角 X 关闭它，其他标签瞬间丝滑？这，就是多进程的功劳。
4. 渲染进程内部：其实是多线程的！
很多人说“浏览器是单线程”——错！只有 JavaScript 是单线程的。
一个渲染进程内部其实有多个线程：
- 主线程（Main Thread）：执行 JS、解析 HTML/CSS、布局、绘制（Paint）、样式计算
- 合成线程（Compositor Thread）：负责合成位图，处理 transform/translate3d、opacity、filter 等不触发重排重绘的属性
- 栅格线程（Raster Thread）：将图层栅格化为位图，多线程并行，极大提升滚动性能
- IO 线程：处理 IPC 消息、网络请求回调等
这就是为什么你写 CSS transform: translateZ(0) 或 will-change: transform 能让元素提升为独立图层，由合成线程独立处理，60fps 丝滑滚动。
2023 年 Chrome 推出的 Threaded Scrolling 和 Raster Isolation 进一步把栅格化也多线程化，滚动更流畅。
5. 一个真实页面到底会产生多少进程？（亲测）
我现在（2025.12.05）打开几个典型网站，Shift+Esc 看进程：
- 只开一个空标签：5 个进程（主 + GPU + 网络 + 2 个 utility）
- 打开掘金首页：13 个进程（多了 1 个渲染进程 + 几个 worker）
- 打开 B 站播放视频：22 个进程（视频解码、WebGL、广告 iframe 都拆进程）
- 打开含 iframe 的企业后台（跨域）：能轻松上 30 个进程
这才是真实使用场景。
6. 多进程的代价与优化
多进程牛逼，但代价是内存占用高。
早期 Chrome 被骂“吃内存怪兽”，2018 年后 Chrome 做了大量优化：
- Process-per-site（同一站点共享渲染进程）
- Site Isolation 可通过 chrome://flags 关闭（但不建议）
- Memory Saver 模式（冻结不活跃标签的渲染进程）
- Tab Discard + Tab Freeze
- 2024 年推出的 Memory Partitioning 进一步降低单个站点内存峰值
现在普通机器开 50 个标签才 4～6GB，远好于当年。
7. 开发者最该关心的三件事
- 为什么你的页面卡？99% 是主线程堵塞 → 用 Performance 面板看 Main Thread 是否有长任务
- 为什么动画卡？可能是触发了重排重绘 → 提升图层、用 transform/opacity、will-change
- 为什么内存暴涨？可能是开了太多 iframe 或 Web Worker 没回收 → 合理使用 SharedWorker，及时 terminate() Worker
8. 未来：Chrome 正在走向“更极致的多进程”？
2025 年 Chrome 团队在 Chromium Blog 透露正在实验 Manifest V3 扩展全面进程隔离 + WebAssembly 多线程支持 + Project Fugu 新 API（File System Access 等）更细粒度权限控制。
但核心架构十几年没变，依然是那个 2008 年震惊世界的多进程 + 沙箱模型。
总结
Chrome 之所以能碾压所有对手，靠的不是 V8 快，不是 Blink 强，而是从底层架构就全面拥抱多进程 + 沙箱安全模型。
- 一个页面崩溃不影响全局
- 恶意网站几乎无法突破沙箱
- GPU 加速让网页媲美原生应用
- 站点隔离防御 spectre 类攻击
正是这个架构，让 Chrome 从 2008 年一个“小众极客浏览器”，变成今天无人能敌的霸主。
下次再有人说“浏览器不就是解析 HTML 吗”，你就把这篇文章甩给他。
这就是 Chrome 能统治浏览器界 17 年的真正底层原因。
