1. 背景
最近在使用 Firefox 时遇到两个明显问题：
- Firefox 看起来占用内存较高；
- 偶发出现整个系统黑屏、卡死的情况。
为了判断问题到底是 Firefox 内存泄漏、网页占用过高、扩展异常，还是显卡/硬件加速相关问题，我导出了 Firefox 的 about:memory 内存报告，并对其中的进程、内存类型、扩展、GPU/WebRender 使用情况进行了分析。
本文记录这次分析过程、关键数据、结论以及建议的解决方案。
2. 报告基本情况
本次分析的报告来自 Firefox 的内存分析文件：
memory-report.json
报告中包含多个 Firefox 进程：
Main Process
GPU
Socket
RDD
Utility
prealloc
webIsolated=https://cnblogs.com
webIsolated=https://bing.com
webIsolated=https://github.com
privilegedabout
extension
这说明当前 Firefox 采用了典型的多进程架构：
- 主进程负责浏览器核心逻辑；
- Web 内容进程负责不同站点页面；
- Extension 进程负责扩展；
- GPU 进程负责 WebRender、合成、纹理等图形任务；
- Socket、RDD、Utility 等为网络、媒体解码、沙箱工具进程。
3. 先区分几个容易误解的内存指标
Firefox 的 about:memory 报告里有很多指标，其中最容易被误解的是 vsize、address-space 和 wasm-guard-pages。
3.1 resident
resident 表示进程当前驻留在物理内存中的内存量。
它比任务管理器里的某些统计更接近“实际正在占用 RAM”的概念，但仍可能包含共享页。
3.2 resident-unique
resident-unique 表示该进程独占的物理内存。
这个指标通常更适合判断“这个进程真正额外吃掉了多少内存”。
3.3 explicit
explicit 是 Firefox 自己能够解释和分类的内存。
它通常小于实际 resident，因为不是所有内存都能被 Firefox 精确归因。
3.4 vsize
vsize 是虚拟地址空间大小。
在 64 位系统上，虚拟地址空间可以非常大，报告里出现几 TB 甚至更大的数字并不代表实际占用了对应大小的物理内存。
本次报告中 vsize 数字非常大，但不能将它理解为 Firefox 真正占用了几十 TB 内存。
3.5 wasm-guard-pages
本次报告中出现：
wasm-guard-pages: 4125.19 MB
这个数字看起来很吓人，但它主要是 WebAssembly 运行时保留的 guard pages，属于虚拟地址空间保护机制，不等于实际吃掉 4GB 物理内存。
因此，这不是本次问题的核心。
4. 总体内存占用情况
从报告汇总来看：
| 指标 | 数值 |
|---|---|
| resident 总量 | 约 1865 MB |
| resident-unique 总量 | 约 1213 MB |
| private 总量 | 约 1555 MB |
| explicit 总量 | 约 692 MB |
| heap-allocated | 约 474 MB |
| JS runtime | 约 465 MB |
| window-objects | 约 31 MB |
| GPU committed | 约 249 MB |
| GFX/WebRender | 约 239 MB |
| wasm-guard-pages | 约 4125 MB，主要是虚拟地址保留 |
从这些数据看，Firefox 当前真实物理内存占用大约在 1.2GB 到 1.9GB 之间。
这个占用不能说特别低，但对于现代 Firefox、多个标签页、多个扩展同时运行的场景，并不属于明显异常的内存爆炸。
换句话说：
这份报告并不支持“Firefox 发生了严重内存泄漏并直接把系统内存吃光”的判断。
5. 各进程内存占用分析
按 resident-unique 排序，各进程大致如下：
| 进程 | resident | resident-unique | explicit | heap | JS runtime |
|---|---|---|---|---|---|
| Main Process | 466.82 MB | 297.04 MB | 166.87 MB | 163.07 MB | 55.68 MB |
| GitHub 内容进程 | 273.09 MB | 206.58 MB | 139.99 MB | 95.49 MB | 114.14 MB |
| Extension 扩展进程 | 245.29 MB | 185.04 MB | 137.99 MB | 71.67 MB | 112.58 MB |
| Bing 内容进程 | 249.73 MB | 182.21 MB | 115.21 MB | 53.84 MB | 100.81 MB |
| GPU 进程 | 181.59 MB | 137.31 MB | 12.05 MB | 17.42 MB | 0 MB |
| cnblogs 内容进程 | 183.57 MB | 115.84 MB | 72.97 MB | 38.59 MB | 58.05 MB |
| privilegedabout | 110.03 MB | 51.09 MB | 32.54 MB | 21.07 MB | 19.24 MB |
可以看到，主要内存来自以下几类：
- 浏览器主进程；
- GitHub、Bing、cnblogs 等网页内容进程；
- 扩展进程；
- GPU 进程。
其中 GitHub 和 Bing 的 JS runtime 都超过 100MB，说明这些页面本身的 JavaScript 状态较重，但仍处在常见范围内。
6. 扩展内存分析
报告中识别到的扩展包括：
| 扩展 | 说明 |
|---|---|
| Bitwarden Password Manager | 密码管理器 |
| Wappalyzer | 技术栈识别工具 |
| easyScholar | 学术相关扩展 |
| Zotero Connector | Zotero 浏览器连接器 |
| 欧路翻译 | 划词/网页翻译工具 |
| 恢复关闭的标签页 | 标签页恢复工具 |
| Wallabagger | 稍后读/网页保存相关工具 |
| IPvFoo | 网络/IP 信息显示 |
| 其他 Mozilla 内置扩展 | Picture-in-Picture、Form Autofill 等 |
扩展进程中的路径累计内存大致如下：
| 扩展 | 路径累计内存 |
|---|---|
| Bitwarden Password Manager | 约 42.58 MB |
| Wappalyzer | 约 20.69 MB |
| Zotero Connector | 约 5.07 MB |
| 欧路翻译 | 约 3.93 MB |
| 恢复关闭的标签页 | 约 3.02 MB |
内容脚本中也看到：
| 内容脚本 | 估算内存 |
|---|---|
| easyScholar | 约 18.12 MB |
| Bitwarden Password Manager | 约 7.15 MB |
需要注意：扩展路径累计内存可能存在重复统计，不能简单相加当作真实总量。不过它可以帮助定位哪些扩展更活跃。
从数据看，Bitwarden、Wappalyzer、easyScholar 相对更显眼，但它们并没有表现出单个扩展吃掉数百 MB 或数 GB 内存的异常。
结论是：
扩展有一定内存消耗，但暂时不像本次黑屏卡死的首要原因。
不过，如果要做排查，可以优先临时禁用这些扩展进行验证：
- Wappalyzer；
- easyScholar；
- 欧路翻译；
- Zotero Connector；
- Bitwarden。
Bitwarden 涉及 WebAssembly 相关内存，但本次报告中实际物理占用并不异常。
7. GPU/WebRender 分析
本次报告中最值得关注的是 GPU 相关指标。
GPU 进程关键数据如下：
| 项目 | 数值 |
|---|---|
| GPU 进程 resident | 181.59 MB |
| GPU 进程 resident-unique | 137.31 MB |
| gpu-committed | 249.19 MB |
| gpu-shared | 146.65 MB |
| gpu-dedicated | 142.64 MB |
| gfx/webrender 总量 | 约 238.75 MB |
WebRender 纹理细分：
| 项目 | 数值 |
|---|---|
| render-targets | 84.88 MB |
| texture-cache/atlas | 39.50 MB |
| depth-targets | 35.50 MB |
| picture-tiles | 32.00 MB |
| swap-chains | 29.23 MB |
| upload-staging-textures | 6.25 MB |
| render-texture-hosts | 5.21 MB |
这些数据说明 Firefox 正在较明显地使用 GPU 硬件加速和 WebRender。
如果只是普通内存高，通常表现为系统变慢、开始换页、程序响应迟钝；但如果表现是：
- 整个系统突然黑屏；
- 鼠标键盘无响应；
- 屏幕短暂黑一下再恢复；
- 或需要强制重启；
这更像是 GPU 驱动、硬件加速、显存/共享显存、WebRender 或驱动 TDR 相关问题。
Windows 上这类问题常见于：
- 显卡驱动崩溃或超时恢复；
- Firefox WebRender 与当前驱动组合不稳定；
- 硬件加速触发某些页面或扩展的图形路径问题；
- 独显/集显切换异常；
- 显存压力、驱动 bug 或系统图形栈问题。
因此，本次报告更支持下面这个判断：
Firefox 内存占用并没有严重异常；系统黑屏和卡死更可能与 GPU 硬件加速、WebRender 或显卡驱动有关。
8. 为什么不是单纯内存泄漏？
判断是否为内存泄漏，需要看是否存在某个进程或模块持续异常增长，并且达到远超正常范围的水平。
本次报告中：
- Firefox 独占物理内存约 1.2GB；
- 总 resident 约 1.9GB；
- 单个网页进程没有达到数 GB；
- 扩展进程约 245MB resident；
- GPU 进程约 181MB resident；
- 网络缓存只有约 7.6MB；
- 图像缓存本身也没有表现出异常爆炸。
这些数字更像是“多个现代网页 + 多个扩展 + GPU 加速”的正常偏高状态，而不是严重泄漏。
同时，黑屏卡死这种症状比普通内存压力更偏向图形栈问题。
9. 解决方案一：关闭 Firefox 硬件加速
这是最优先建议尝试的方案。
操作步骤：
- 打开 Firefox 右上角三横线菜单；
- 进入“设置”；
- 选择“常规”；
- 下拉到“性能”；
- 取消勾选“使用推荐的性能设置”；
- 取消勾选“使用硬件加速模式，如果可用”；
- 重启 Firefox。
如果关闭硬件加速后黑屏和卡死明显消失，那么基本可以判断问题来自 GPU/驱动/WebRender 路线。
关闭硬件加速的代价是：
- 视频播放、页面滚动、复杂图形页面可能略微增加 CPU 占用；
- 某些动画或高分辨率页面可能没那么流畅；
- 但稳定性通常会提高。
对于频繁黑屏卡死的场景，稳定性优先级通常高于这一点性能损失。
10. 解决方案二：调整内容进程数量
Firefox 的多进程架构可以提升隔离性和稳定性，但也会增加内存占用。
如果标签页较多，可以降低内容进程数量来减少内存峰值。
10.1 图形界面设置
路径：
设置 → 常规 → 性能
先取消：
使用推荐的性能设置
然后查看是否出现：
内容进程限制
可以设置为：
| 值 | 效果 |
|---|---|
| 8 | 默认或偏高，多标签性能好，内存占用高 |
| 4 | 推荐折中值 |
| 2 | 更省内存，适合内存压力明显的机器 |
| 1 | 最省内存，但多标签性能明显下降 |
建议先设为 4。
10.2 如果界面里看不到“内容进程限制”
新版 Firefox 或某些配置下可能隐藏该选项，可以通过 about:config 修改。
步骤：
- 地址栏输入：
about:config
- 搜索：
dom.ipc.processCount
- 修改值：
4
- 重启 Firefox。
如果仍然觉得内存压力较高，可以再尝试设为：
2
不建议一开始就设为 1，因为会明显影响多标签并发性能。
11. 解决方案三：逐个禁用扩展排查
虽然本次报告不支持“扩展严重泄漏”的判断，但扩展仍然可能触发页面卡顿、内容脚本膨胀、GPU 路径异常或兼容性问题。
建议用二分法排查：
- 先禁用非必要扩展；
- 使用一段时间观察是否还会黑屏；
- 如果稳定，再逐个启用扩展；
- 找到触发问题的扩展组合。
优先排查这些扩展：
- Wappalyzer；
- easyScholar；
- 欧路翻译；
- Zotero Connector；
- Bitwarden。
其中 Wappalyzer、easyScholar、翻译类扩展都会在网页中注入内容脚本，理论上更容易与复杂网页产生交互。
Bitwarden 虽然内存相对更高，但它是密码管理器，是否禁用需要结合使用需求。如果要测试，建议只做短时间排查。
12. 解决方案四：检查显卡驱动和 Windows 事件日志
如果 Firefox 关闭硬件加速后问题消失，下一步应该检查显卡驱动。
12.1 检查 Windows 事件查看器
打开：
事件查看器 → Windows 日志 → 系统
重点搜索这些关键词：
Display
nvlddmkm
amdkmdag
igdkmdn64
igfx
LiveKernelEvent
TDR
如果看到类似：
Display driver stopped responding and has recovered
或者 NVIDIA/AMD/Intel 驱动相关错误，就说明黑屏很可能是显卡驱动超时或崩溃。
12.2 更新或回退显卡驱动
如果最近更新过驱动后才开始出现问题，可以尝试回退到稳定版本。
如果驱动很久没更新，可以尝试更新到显卡厂商官网版本。
对于笔记本或移动工作站，建议优先使用设备厂商提供的稳定驱动，其次再考虑 NVIDIA/AMD/Intel 官网驱动。
12.3 固定 Firefox 使用集显或独显
如果机器有集显和独显，可以在 Windows 图形设置中指定 Firefox 使用某一个 GPU。
路径大致为：
Windows 设置 → 系统 → 显示 → 图形
添加 Firefox 后，分别测试：
- 节能模式，即集显；
- 高性能模式，即独显。
如果某一种模式明显稳定，就可以固定使用。
13. 解决方案五：继续采集对比报告
单份 about:memory 报告只能说明某一时刻的状态。
如果要判断是否存在持续增长的泄漏，建议采集多份报告：
- Firefox 刚启动后采集一份；
- 正常使用 1 小时后采集一份；
- 出现明显卡顿前采集一份；
- 黑屏恢复后如果还能操作，再采集一份。
然后对比：
- 哪个进程增长最快；
- JS runtime 是否持续增长；
- extension 进程是否持续增长；
- GPU committed 是否持续增长；
- 某个标签页是否持续增长。
如果是内存泄漏，通常会看到某个进程或某类对象持续单调增长，且关闭对应标签页或扩展后不能释放。
14. 推荐排查顺序
综合本次报告，建议按下面顺序操作：
第一步：关闭硬件加速
这是最关键的一步。
设置 → 常规 → 性能 → 取消“使用推荐的性能设置” → 取消“使用硬件加速模式，如果可用”
重启 Firefox 后观察是否还会黑屏。
第二步：将内容进程限制设为 4
如果界面里没有该选项，就在 about:config 修改：
dom.ipc.processCount = 4
第三步：禁用高活跃扩展测试
优先测试：
Wappalyzer
easyScholar
欧路翻译
Zotero Connector
Bitwarden
第四步：检查显卡驱动和系统日志
重点看 Windows 事件查看器中是否有显卡驱动重置、TDR、LiveKernelEvent 等记录。
第五步：多次采集 about:memory 报告对比
如果关闭硬件加速后仍然出现问题，再继续判断是否有特定网页或扩展在持续泄漏。
15. 最终结论
根据本次 about:memory 报告，Firefox 的物理内存占用约为 1.2GB 到 1.9GB。
这个数字偏高，但不构成严重异常，也没有看到某个网页或扩展单独吃掉数 GB 内存的证据。
真正值得关注的是 GPU/WebRender 相关资源：
gpu-committed: 约 249 MB
gfx/webrender: 约 239 MB
再结合“整个系统黑屏、卡死”这一现象，最可能的方向不是普通内存泄漏，而是：
Firefox 硬件加速 / WebRender / 显卡驱动 / GPU 调度之间存在兼容性或稳定性问题。
因此，最推荐的解决方案是：
- 关闭 Firefox 硬件加速；
- 将内容进程限制设为 4；
- 逐个禁用 Wappalyzer、easyScholar、翻译类扩展、Zotero Connector 等扩展测试；
- 检查 Windows 事件查看器中的显卡驱动错误；
- 必要时更新或回退显卡驱动。
如果关闭硬件加速后黑屏问题消失，基本就可以确认问题主要在 GPU/驱动/WebRender 路径，而不是 Firefox 单纯内存占用过高。