谷歌浏览器动不动开几十个进程，这其实是设计使然

打开任务管理器，往下翻，能看到几十个谷歌浏览器的进程。

只开了三五个网页，进程数却是这个量级。第一反应通常是：是不是中毒了，或者哪里出问题了。

不是。这是它的设计。

而且正是因为这套设计，你的浏览器才不容易整个崩掉。

一个网页崩了，为什么别的没事

先说这个设计要解决的问题。

早期的浏览器是单进程的：所有标签页、所有页面代码，全跑在同一个进程里。

后果很直接——任何一个页面出问题，整个浏览器跟着挂。 一个广告脚本死循环，所有标签页一起卡死；一个页面内存溢出，浏览器直接消失。

Chrome 换了个思路：把不同的任务拆到不同的操作系统进程里。

谷歌浏览器现在的结构大致是这样：

• 浏览器进程：主控——地址栏、书签、网络请求调度、权限管理
• 渲染进程：把 HTML/CSS/JS 变成你能看见、能点的页面
• GPU 进程：图形绘制、硬件加速
• 网络进程：处理网络请求
• 插件 / 扩展进程：各自独立运行

进程之间内存是隔离的。

所以某个渲染进程崩了，操作系统会回收它——但浏览器进程还在，其他标签页还在。你看到的只是某一个页面变成"页面崩溃"的提示，关掉重开就行。

代价是什么？每个进程都有自己独立的内存空间。 同样一个网页，多进程模式下占用的内存比单进程多。

这就是谷歌浏览器 "吃内存" 的根本原因。

为什么进程数远多于标签页数

回到开头那个现象。

即使只开三个网页，进程数也可能上十个。多出来的部分，主要是站点隔离（Site Isolation）造成的。

站点隔离在防什么

设想一个场景：你在 A 网站的页面里，嵌入了 B 网站的内容（比如一个第三方评论框，或者一段广告）。

如果它们共享同一个渲染进程，那么 B 的代码理论上能访问到同一块内存里的 A 的数据——包括你的登录状态。

更麻烦的是侧信道攻击（比如 Spectre 这类）：即使代码没有直接读取权限，也能通过测量内存访问时间等方式推测出内容。

站点隔离的对策很直接：不同站点的内容，强制放进不同的进程。

具体到实现：

• 主页面占一个渲染进程
• 跨站的 iframe 单独再开一个进程——这叫 OOPIF（Out-of-Process Iframe）

所以一个看起来"只有一个页面"的标签，实际可能对应好几个进程。

你看到进程数多，恰恰说明防护在生效。

顺带一提：沙箱

每个渲染进程还跑在沙箱里，对文件系统、系统调用的访问被严格限制。

这意味着即使某个页面被攻破，攻击者拿到的也只是沙箱内的权限，碰不到你的系统。

这是"多建进程"换来的另一项收益。

进程多，也带来一个好处

不只是稳定性。

现代 CPU 都是多核的。多进程意味着可以把不同页面的计算任务分派到不同核心上并行处理——一个页面在跑复杂脚本，不会拖住其他页面的响应。

所以这套设计其实是三笔交易：

• 更多内存占用：稳定性（单页崩溃不扩散）
• 更多进程管理开销：安全性（站点隔离 %2B 沙箱）

理解了这笔交易，"谷歌浏览器吃内存" 就不是故障，而是必然。

那内存不够怎么办

既然是设计使然，就没法"关掉"。但可以做两件事：看清谁在占，以及让不用的页面让出内存。

看清谁在占：Chrome 自带的任务管理器

按 Shift %2B Esc。

这不是系统的任务管理器——它只列 Chrome 内部的进程，而且按标签页和扩展程序分组。

点"内存占用"这一列排序，谁占得多一目了然。

这比在系统任务管理器里对着一堆同名进程猜要准确得多。

看到某个页面或扩展占用异常，直接选中 → 结束进程。

让不用的页面让出内存

新版谷歌浏览器内置了内存节省模式。

地址栏输入：

chrome://settings/performance

打开"内存节省模式"。

它的做法是"丢弃"（Discard）后台标签页。

注意这个词——丢弃不是关闭。

标签页还留在标签栏上，标题和图标都在。但它对应的渲染进程被销毁了，内存被释放。等你点回去，谷歌浏览器会自动重新加载页面。

从体感上说，就像你自己刷新了一下。

哪些页面不会被丢弃

不是所有后台标签都会被清理。以下情况会被保护：

• 正在播放音频或视频
• 正在进行视频会议等实时通信
• 正在上传或下载文件
• 你手动加入"始终不进入休眠"列表的站点

如果你有页面不希望被休眠——比如常驻的监控面板——在同一个设置页把它加进白名单。

一个能看穿"丢弃决策"的页面

这个地址知道的人不多：

chrome://discards

它列出所有标签页，以及每个标签的丢弃优先级评分。

换句话说，谷歌浏览器打算先扔掉谁，在这里能看到。

页面上还提供手动操作：

• Urgent Discard——立刻丢弃某个标签
• Load——重新加载

对做 Web 开发的人来说，这个页面可以用来测试自己的站点被丢弃后能否正常恢复。

给开发者的一点提醒

如果你在做单页应用（SPA），有个坑值得注意：

标签页被丢弃时，不会触发 beforeunload、pagehide、unload 这些事件。

所以不要依赖这些事件来保存用户状态——被丢弃时它们根本不会执行。

两点建议：

把状态实时存起来。用户输入、草稿、进度这类数据，随手写进 localStorage 或同步到服务端，别攒到页面卸载时再存。

可以用 document.wasDiscarded 判断。这个属性会告诉你当前页面是不是从丢弃状态恢复回来的，如果是，可以借此做数据重连或状态复原。

几个顺手的小操作

重启浏览器但保留标签页

chrome://restart

浏览器会重启，同时把当前所有标签页恢复出来。跑久了感觉变卡时，用这个比手动关掉重开省事。

检查扩展程序

chrome://extensions/

很多卡顿的源头是插件。每个扩展都在独立进程里跑，装多了内存和 CPU 都会有压力。不常用的直接禁用。

一句总结

"谷歌浏览器占内存"这件事，本质上是它拿内存换了稳定性、安全性和多核并行。

这笔交易值不值，取决于你的机器和用法。内存充足的话，享受它带来的隔离就好；内存紧张，就用内存节省模式把不用的页面交出去。

真正没必要的，是看到进程列表就慌——那几十个进程，是它在正常工作。