这是一个真正的问题，这就是为什么在服务器和嵌入式系统中使用ECC内存。以及为什么飞行系统与地面系统不同。

For example, note that Intel parts destined for "embedded" applications tend to add ECC to the spec sheet. A Bay Trail for a tablet lacks it, since it would make the memory a bit more expensive and possibly slower. And if a tablet crashes a program every once in a blue moon, the user does not care much. The software itself is far less reliable than the HW anyway. But for SKUs intended for use in industrial machinery and automotive, ECC is mandatory. Since here, we expect the SW to be far more reliable, and errors from random upsets would be a real issue.

通过IEC 61508和类似标准认证的系统通常都有启动测试，检查所有RAM是否正常(没有位卡在0或1)，以及运行时的错误处理，试图从ECC检测到的错误中恢复，通常还有内存清除任务，不断地遍历和读写内存，以确保发生的任何错误都能被注意到。

但是对于主流PC软件来说呢?没什么大不了的。对于长期存在的服务器?使用ECC和故障处理程序。如果一个不可纠正的错误杀死了内核，那就这样吧。或者你偏执地使用带有锁步执行的冗余系统，这样如果一个核心损坏，另一个核心可以在第一个核心重新启动时接管。

我曾经为在太空中飞行的设备编程，然后你(据说，没有人给我看过任何关于这方面的论文，但据说这是业内的常识)可以预期宇宙射线总是会导致错误。

更常见的情况是，噪声会破坏数据。校验和可以在很多层面上解决这个问题;在数据线中，通常有一个奇偶校验位与数据一起传输。这大大降低了腐败的可能性。然后在解析级别上，无意义的数据通常会被忽略，因此即使某些损坏确实通过了奇偶校验位或其他校验和，在大多数情况下也会被忽略。

此外，一些组件被电屏蔽以屏蔽噪音(我猜可能不是宇宙射线)。

但最后，正如其他回答者所说，偶尔会有位或字节被打乱，这取决于它是否是有效字节。最好的情况是，宇宙射线扰乱了其中一个空比特，完全没有影响，或者使计算机崩溃(这是一件好事，因为计算机避免了伤害);但最坏的情况，我相信你可以想象。

好吧，显然是宇宙射线导致丰田汽车的电子设备出现故障，所以我想说这种可能性非常高:)

宇宙射线真的导致了丰田的灾难吗?

我经历过这种情况——宇宙射线翻转一点并不罕见，但一个人观察到这种情况的可能性很小。

2004年，我正在为一个安装程序开发一个压缩工具。我的测试数据是一些Adobe安装文件，压缩了大约500 MB或更多。

在冗长的压缩运行和解压运行以测试完整性之后，FC /B显示一个字节不同。

在这一个字节内，MSB翻转了。 我也急了，担心我有一个疯狂的bug，它只会在非常特定的条件下出现——我甚至不知道从哪里开始寻找。

但有声音让我再做一次测试。我运行它，它通过了。我设置了一个脚本，在一夜之间运行测试5次。到了早上，5个都已经过去了。

所以这绝对是宇宙射线位翻转。

维基百科引用了IBM在90年代的一项研究，该研究表明“计算机通常每个月每256兆字节的RAM中会出现一次宇宙射线引起的错误。”不幸的是，引用的是《科学美国人》上的一篇文章，该文章没有提供任何进一步的参考文献。就我个人而言，我发现这个数字非常高，但也许大多数由宇宙射线引起的记忆错误不会引起任何实际或明显的问题。

另一方面，当涉及到软件场景时，人们谈论概率通常不知道他们在谈论什么。