引言
你有没有遇到过这样的情况：某个标签页突然卡住不动了，但其他标签页依然可以正常浏览、切换？为什么一个网页崩溃不会拖垮整个浏览器？答案就藏在Chrome的多进程架构里。
一、从“打开一个页面，为什么有6个进程”说起
打开Chrome的任务管理器（点击右上角菜单 → 更多工具 → 任务管理器，或者直接按 Shift + Esc），你会发现一件有趣的事情：明明只打开了一个标签页，任务管理器里却出现了好几个Chrome进程。
一个页面为什么要启动这么多进程？这得从浏览器的架构演进说起。
在2007年以前，市面上的浏览器基本都是单进程架构——所有的功能模块（网络、插件、JS引擎、渲染引擎等）都运行在同一个进程里。这种架构存在三大致命缺陷：
不稳定：一个插件崩溃或者一个页面的脚本出错，就会导致整个浏览器崩溃
不流畅：某个页面的死循环脚本会让整个浏览器卡死，所有标签页都跟着遭殃
不安全：所有页面共享同一块内存，恶意网页可以通过内存漏洞获取系统权限
为了解决这些问题，Google在2008年推出Chrome时，率先采用了多进程架构。正如Chromium官方文档所说：“构建一个永不崩溃或永不卡顿的渲染引擎几乎是不可能的，构建一个绝对安全的渲染引擎也几乎是不可能的。”多进程架构的思路，就是把每个网页放进独立的进程里，就像现代操作系统把不同的应用程序隔离开一样。
二、进程与线程：先搞懂两个基础概念
在深入之前，我们先弄懂两个基础概念。
进程（Process） 是操作系统资源分配的基本单位。启动一个程序时，操作系统会为它创建一块独立的内存空间，用来存放代码、运行中的数据。可以把它理解成一个 “工厂” ——每个工厂有自己独立的地盘和资源。
线程（Thread） 是进程内的执行单元，是CPU调度的最小单位。可以把它理解成工厂里的 “工人” ——同一个工厂里的工人共享工厂的资源（内存），但不同工厂的工人不能直接跑到别的工厂里去干活。
进程和线程之间有几个关键特点：
进程中的任意一线程执行出错，会导致整个进程崩溃
不同进程之间相互隔离，一个进程崩溃不影响其他进程
不同进程无法直接访问彼此的内存数据
同一个进程内的多个线程共享进程的内存空间
这正是多进程架构能够实现“标签页隔离”的底层基础——一个渲染进程崩溃了，其他进程完全不受影响。
三、Chrome的五大核心进程
现代Chrome浏览器采用 “1主+N子” 的进程模型，主要包括以下几类核心进程：
浏览器主进程（Browser Process）—— 总指挥
浏览器主进程是整个浏览器的 “大脑”和“总指挥” 。它负责：
管理浏览器UI界面（地址栏、书签、标签页等）
控制子进程的创建、管理和终止
处理用户输入（点击、键盘事件）
管理存储（Cookie、localStorage等）
协调各个进程间的通信
关键点：浏览器主进程是Chrome中唯一具有高权限的进程，可以直接访问操作系统资源。但它不直接渲染网页内容。
渲染进程（Renderer Process）—— 每个标签页的独立战场
渲染进程是前端开发者最需要关注的进程。每个标签页（或站点）默认对应一个独立的渲染进程。它的核心任务是将HTML、CSS和JavaScript转换为用户可以与之交互的网页。
渲染进程内部运行着两大核心引擎：
Blink引擎：负责解析HTML/CSS，构建DOM树和CSSOM树
V8 JavaScript引擎：负责执行JavaScript代码
出于安全考虑，渲染进程运行在 “沙箱模式” 下，权限受到严格限制，无法直接访问操作系统资源。
一个渲染进程内部也是多线程的，主要包括：
主线程（Main Thread） ：执行JS、构建DOM、样式计算、布局、生成绘制指令
合成线程（Compositor Thread） ：负责将图层合成并交给GPU渲染
IO线程：负责接收来自其他进程的IPC消息
工作线程（Worker Thread） ：运行Web Worker等后台任务
GPU进程（GPU Process）—— 图形加速器
Chrome刚发布时并没有独立的GPU进程。随着网页越来越复杂，CSS 3D变换、WebGL、视频播放等场景大量使用GPU，Chrome于是将GPU操作独立成一个进程。
GPU进程负责：
页面最终的绘制与合成
处理WebGL、CSS 3D变换
硬件加速视频解码
将GPU操作隔离的好处是：即使GPU驱动出现问题，也不会导致整个浏览器崩溃。
网络进程（Network Process）—— 网络请求大总管
网络进程是后来才从浏览器进程中独立出来的。它专门负责：
所有HTTP/HTTPS请求
DNS解析
资源缓存管理
Cookie管理
连接池和HTTP/2多路复用
安全优势：即使某个页面被XSS攻击，也无法直接操控网络层发起任意请求——所有网络请求都需要通过IPC通信。
插件进程（Plugin Process）—— 插件的隔离舱
插件（如Flash、PDF阅读器）是最容易出问题的模块。Chrome为每个插件单独创建一个进程，这样即使插件崩溃，也不会影响浏览器和其他页面。
小贴士：打开一个页面为什么至少需要4个进程？因为至少需要1个浏览器进程 + 1个GPU进程 + 1个网络进程 + 1个渲染进程。如果页面还跑了插件，还得加上插件进程。
四、进程间如何通信？——IPC与Mojo
进程之间是相互隔离的，那它们怎么协同工作呢？答案是进程间通信（IPC, Inter-Process Communication） 。
比如，渲染进程需要加载一张图片，流程是这样的：
渲染进程通过IPC发送请求给网络进程
网络进程下载完成后，通过IPC将数据传回渲染进程
渲染进程再将数据交给合成线程，最终显示到屏幕
Chrome早期使用传统的IPC框架，但随着浏览器功能越来越复杂，传统IPC逐渐暴露出序列化开销大、类型安全不足、异步处理复杂等问题。
为此，Chrome团队开发了Mojo框架——一个现代化的跨进程通信解决方案。Mojo的优势包括：
强类型接口：通过.mojom文件自动生成类型安全的代码
异步消息传递：原生支持回调，适合高并发
跨语言支持：支持C++、Java、JavaScript等
安全与隔离：每条管道可以设置权限
Chromium官方文档也确认：“浏览器和渲染器使用Mojo或Chromium的传统IPC系统进行通信。”
五、多进程架构的三大优势
回到文章开头的问题：为什么一个标签页崩溃不会让整个浏览器卡死？
答案就在于多进程架构带来的三大优势：
稳定性
进程之间相互隔离。当一个渲染进程崩溃时，影响的仅仅是当前标签页，浏览器主进程和其他标签页的渲染进程完全不受影响。这就是为什么你经常能看到Chrome弹出“噢唷，崩溃啦！”的提示，但其他标签页依然安然无恙。安全性
渲染进程运行在沙箱中，无法直接访问操作系统资源。即使恶意网页利用了渲染进程的漏洞，攻击者也无法突破沙箱获取系统权限。再加上站点隔离（Site Isolation） 技术——不同站点的网页被强制分配到不同的渲染进程中——进一步防御了Spectre等侧信道攻击。性能
多进程架构可以充分利用多核CPU的并行处理能力。渲染、网络、GPU各司其职，一个进程的繁忙不会阻塞其他进程。比如，即使某个页面的JavaScript在主线程上执行耗时任务，合成线程依然可以保证页面的滚动流畅。
六、多进程并非完美——挑战与未来
凡事都有两面性。多进程架构虽然带来了稳定性和安全性，但也带来了新的挑战：
更高的资源占用：每个进程都包含公共基础结构的副本（如V8引擎），消耗更多内存
更复杂的体系架构：模块之间耦合性高，扩展性差
为了解决这些问题，Chrome团队从2016年开始探索面向服务的架构（SOA） 。其核心思想是：将各种功能模块重构成独立的服务（Service） ，每个服务都可以在独立的进程中运行，服务之间通过定义好的接口和IPC通信。
这种架构的优势在于弹性：在性能强大的设备上，服务以多进程方式运行，充分发挥性能优势；在资源受限的设备上，多个服务可以合并到一个进程中运行，节省内存。
目前Chrome正处在从传统多进程架构向服务化架构过渡的阶段，这将是一个漫长的迭代过程。
总结
Chrome的多进程架构，本质上是用 “空间换稳定” ——用更多的内存开销，换来更高的稳定性、安全性和性能。当一个标签页崩溃时，其他标签页依然可以正常工作，这正是多进程隔离带来的最直观的好处。
理解浏览器的多进程架构，不仅能帮你解答“为什么标签页崩溃不会卡死整个浏览器”这样的问题，更能让你站在更高的维度去理解Web应用的性能优化、安全策略和渲染流程。