为啥以前 IE 老"崩溃"，而现在开一堆标签页的 Chrome 还能比较稳？答案都藏在浏览器的「进程模型」里。
作为一个还在学习前端的同学，我经常听到几个关键词：
进程、线程、多进程浏览器、渲染进程、V8、事件循环......
下面就是我目前的理解，算是一篇学习笔记式的分享
一、先把概念捋清：进程 vs 线程
-
进程（Process）
- 操作系统分配资源的最小单位。
- 拥有独立的内存空间、句柄、文件等资源。
- 不同进程间默认互相隔离，通信要通过 IPC。
-
线程（Thread）
- CPU 调度、执行代码的最小单位。
- 共享所属进程的资源（内存、文件句柄等）。
- 一个进程里可以有多个线程并发执行。
简单理解：
- 进程 = 一个"应用实例" （开一个浏览器窗口就是一个进程）。
- 线程 = 应用里的很多"小工人" （一个负责渲染页面，一个负责网络请求......）。
二、单进程浏览器：旧时代的 IE 模型
早期的浏览器（如旧版 IE）基本都是单进程架构：整个浏览器只有一个进程，里面开多个线程来干活。
可以想象成这样一张图（对应你给的"单进程浏览器"那张图）：
-
顶部是「代码 / 数据 / 文件」等资源。
-
下面有多个线程：
- 页面线程：负责页面渲染、布局、绘制。
- 网络线程：负责网络请求。
- 其他线程：例如插件、定时任务等。
-
所有线程共享同一份进程资源。
在这个模型下：
- 页面渲染、JavaScript 执行、插件运行，都挤在同一个进程里。
- 某个插件或脚本一旦崩溃、死循环、内存泄漏，整个浏览器都会被拖垮。
- 多开几个标签页，本质上依旧是同一个进程里的不同页面线程， "一荣俱荣，一损俱损" 。
这也是很多人对 IE 的经典印象：
"多开几个页面就卡死，崩一次，所有标签页一起消失"。
三、多进程浏览器：Chrome 的现代架构
Chrome 采用的是多进程、多线程混合架构。打开浏览器时，大致会涉及这些进程：
-
浏览器主进程（Browser Process）
- 负责浏览器 UI、地址栏、书签、前进后退等。
- 管理和调度其他子进程（类似一个大管家）。
- 负责部分存储、权限管理等。
-
渲染进程（Render Process）
- 核心任务：把 HTML / CSS / JavaScript 变成用户可以交互的页面。
- 布局引擎（如 Blink）和 JS 引擎（如 V8）都在这里。
- 默认情况下，每个标签页会对应一个独立的渲染进程。
-
GPU 进程（GPU Process）
- 负责 2D / 3D 绘制和加速（动画、3D 变换等）。
- 统一为浏览器和各渲染进程提供 GPU 服务。
-
网络进程（Network Process）
- 负责资源下载、网络请求、缓存等。
-
插件进程（Plugin Process）
- 负责运行如 Flash、扩展等插件代码，通常放在更严格的沙箱里。
你给的第一张图，其实就是这么一个多进程架构示意图：中间是主进程，两侧是渲染、网络、GPU、插件等子进程，有的被沙箱保护。
四、单进程 vs 多进程：核心差异一览（表格对比）
下面这张表，把旧式单进程浏览器和现代多进程浏览器的差异总结出来，适合在文章中重点展示：
| 对比维度 | 单进程浏览器（典型：旧版 IE） | 多进程浏览器（典型：Chrome） |
|---|---|---|
| 进程模型 | 整个浏览器基本只有一个进程，多标签页只是不同线程 | 浏览器主进程 + 多个子进程（渲染、网络、GPU、插件...），标签页通常独立渲染进程 |
| 稳定性 | 任意线程（脚本、插件）崩溃，可能拖垮整个进程，浏览器整体崩溃 | 某个标签页崩溃只影响对应渲染进程，其他页面基本不受影响 |
| 安全性 | 代码都在同一进程运行，权限边界模糊，攻击面大 | 利用多进程 + 沙箱：渲染进程、插件进程被限制访问系统资源，需要通过主进程/IPC |
| 性能体验 | 多标签共享资源，某个页面卡顿，容易拖慢整体；UI 和页面渲染耦合严重 | 不同进程之间可以更好地利用多核 CPU，重页面操作不会轻易阻塞整个浏览器 UI |
| 内存占用 | 单进程内存相对集中，但一旦泄漏难以回收；崩溃时损失全部状态 | 多进程会有一定内存冗余，但某个进程关闭/崩溃后，其内存可被系统直接回收 |
| 插件影响 | 插件崩溃 = 浏览器崩溃，体验极差 | 插件独立进程 + 沙箱，崩溃影响有限，可以单独重启 |
| 维护与扩展 | 所有模块耦合在一起，改动风险大 | 进程边界天然分层，更利于模块化演进和大规模工程化 |
五、别被"多进程"骗了：JS 依然是单线程
聊到这里，很多同学容易混淆一个点：
浏览器是多进程的，那 JavaScript 是不是也多线程并行执行了？
答案是否定的：主线程上的 JavaScript 依然是单线程模型。区别在于：
-
在渲染进程内部，有一个主线程负责：
- 执行 JavaScript。
- 页面布局、绘制。
- 处理用户交互（点击、输入等）。
-
JS 代码仍然遵循：同步任务立即执行，异步任务丢进任务队列，由事件循环（Event Loop）调度。
为什么要坚持单线程？
- DOM 是单线程模型，多个线程同时改 DOM，锁会非常复杂。
- 前端开发心智成本可控；不必像多线程语言那样到处考虑锁和竞态条件。
多进程架构只是把：
- "这个页面的主线程 + 渲染 + JS 引擎"
放在一个单独的进程里（渲染进程）。
这也是为什么：
- 一个页面 JS 写了死循环，会卡死那一个标签页。
- 但其他标签页通常还能正常使用，因为它们在完全不同的渲染进程内。
六、从架构看体验：为什么我们更喜欢现在的浏览器？
站在前端开发者角度，多进程架构带来的直接收益有：
-
更好的容错性
-
更高的安全等级
-
更顺滑的交互体验
-
更容易工程化演进
当然，代价也很现实：多进程 = 更高的内存占用。这也是为什么：
- 多开几十个标签，任务管理器里能看到很多浏览器相关进程。
- 但换来的是更好的稳定性、安全性和扩展性------在现代硬件下，这是可以接受的 trade-off。
七、总结
- 早期浏览器采用单进程 + 多线程模式，所有页面、脚本、插件都在同一个进程里，一旦出问题就"全军覆没"。
- 现代浏览器（代表是 Chrome）使用多进程架构：主进程负责调度，各个渲染、网络、GPU、插件进程各司其职，并通过沙箱强化隔离。
- 尽管浏览器整体是多进程的，但单个页面里的 JavaScript 依然是单线程 + 事件循环模型，这点没有变。
- 从用户体验、前端开发、安全性、稳定性来看，多进程架构几乎是全面碾压旧时代单进程浏览器的一次升级。