本文翻译自 Firefox 工程师 Gabriele Svelto 的 Mastodon 帖子，原载于 Hacker News。
背景：一个被忽视的问题
几年前，Firefox 团队设计了一套在崩溃报告中检测 bit-flip（位翻转） 的方法。去年，他们更进一步，部署了一个真正的内存测试器——在浏览器崩溃后，自动在用户机器上运行内存检测。
最近，Firefox 工程师 Gabriele Svelto 查看了这些测试产生的数据，结果令人震惊：他们的检测启发式算法是可靠的，大量崩溃确实来自内存故障或不稳定的硬件。
数据揭示的真相
让我们看看具体数字：
- 一周内收到约 47 万份崩溃报告（这是 opt-in 系统，实际数字要大得多）
- 其中约 2.5 万份被检测为可能存在 bit-flip
- 这意味着每 20 次崩溃中就有 1 次可能是由坏内存或不稳定内存引起的
而且，由于这是保守估计，实际数字可能至少是两倍。
换句话说：
高达 10% 的 Firefox 崩溃不是软件 Bug，而是由硬件缺陷引起的！
如果排除资源耗尽类崩溃（如 OOM），这个数字甚至上升到 15%。
内存测试器的验证
为了验证这个估计，Firefox 团队查看了运行内存测试器的用户数据：
每 2 次被怀疑由 bit-flip 引起的崩溃中，内存测试器就发现 1 次真正的硬件问题。
需要注意的是，这个测试器并不是对整个机器 RAM 进行全面测试：
- 只检查最多 1 GiB 内存
- 运行时间不超过 3 秒
即使如此受限，它仍然发现了大量真实问题！
这不仅仅是电脑的问题
这个问题影响所有设备：
- 电脑
- 手机
- 路由器
- 打印机
- 你能想到的任何电子设备
即使是那些 RAM 焊接在 CPU 封装上的 ARM MacBook，Firefox 也收到了大量来自这些设备的崩溃报告。想更换这种 RAM？没有专业设备和熟练技师，基本不可能。
行业为何忽视这个问题？
硬件厂商和大型软件厂商多年来一直在回避这个问题，声称软件 Bug 更常见。
但 Firefox 的测试数据表明：硬件问题已经频繁到经常淹没软件问题的程度。
这是一个系统性失败。用户机器上安装了大量 RAM，但很少有用户会用 Memtest86 这样的工具进行长时间测试。偶尔崩溃？很多人已经习以为常。
为什么 ECC 内存不是标配？
ECC（Error-Correcting Code）内存 可以检测和纠正单比特错误，能显著延长消费电子产品的寿命。但：
- 用户不愿意支付约 12% 的溢价
- 主板需要额外逻辑支持
- 行业缺乏推动力
讽刺的是，Windows 自带的内存测试工具被批评为”笑话”——它经常漏掉 Memtest86 能轻易发现的问题。
物理地址与崩溃频率
用户机器上坏比特的位置很重要：
- 如果坏比特在较低的物理地址范围，用户会遇到更多问题
- 即使是轻负载的机器，这些区域也更可能被使用
- 一个坏比特需要命中重要数据（如指针或指令）才会导致崩溃
有用户分享了一个有趣的经历：他的笔记本在物理地址范围末尾有一个坏比特，只有在构建 Firefox OS（当时需要同时编译 Firefox 和大量 Android 基础系统）时才会触发。正常使用根本不会用到那个地址。
机器年龄与故障相关性
Firefox 的数据显示：
机器年龄与观察到的故障数量之间存在极强的相关性。
RAM 会随着时间老化，使用越多越容易出问题。这也是为什么服务器虽然有 ECC 内存，但其运行环境（温度控制、电源稳定、较低时钟频率）与消费设备完全不同，不能直接比较故障率。
文件系统的隐患
最糟糕的情况是什么？
当要写入磁盘的数据恰好包含 bit-flip 时，错误会永久保存到硬盘上。
这也是为什么优秀的文件系统应该对数据和元数据都实现 checksum（校验和），以便在造成永久损坏之前尽早检测到这些问题。
对开发者的启示
- 不要假设所有崩溃都是软件 Bug - 特别是无法复现的崩溃
- 内存测试是重要的 - 新机器应该跑 Memtest86，老机器也应该定期检查
- ECC 内存值得考虑 - 对于重要工作，额外的成本可能物有所值
- 代码体积影响崩溃率 - 理论上，更小的二进制文件会有更低的物理错误概率
结语
Firefox 团队的这项研究揭示了一个被行业长期忽视的问题。10-15% 的崩溃来自硬件故障，这个数字远超之前的任何估计。
下次遇到神秘崩溃时，在疯狂调试代码之前，也许该先跑一下内存测试。
关键要点：
- Firefox 数据显示 1/20 的崩溃可能由内存问题引起
- 实际比例可能高达 10-15%
- 问题影响所有设备，包括无法更换 RAM 的现代笔记本
- 行业长期低估了硬件故障的频率
- ECC 内存应该成为消费电子的标配