您可能会像我一样惊讶地发现，当浏览器在您的页面上崩溃时，Chrome 公开了一个 API 来通知您。它是一个更大的报告 API的一部分，该 API 旨在为浏览器提供一个渠道来通知您（开发人员）崩溃和其他事情。
特别是对于页面崩溃，您不再有页面或 JS 上下文来接收事件，因此 API 而是将一些 JSON 发布到您提供的 URL。通常有两个稍微不兼容的 API 版本，我想是因为他们试图标准化。 （我对这个空间了解不多，但目前看来所有这些都仅限于 Chrome……）
Figma 是一个大型复杂的网络应用程序，经常会破坏浏览器，它使用这些来监控崩溃。这就是我了解到这些系统存在的方式——我正在随叫随到，并发出了关于崩溃率的警报。
这是第二个惊喜出现的地方：由于崩溃率高而触发警报，但监控崩溃率的单独仪表板似乎很低。事实证明，差异是由错误配置引起的。我们根据它们影响站点的哪个部分对传入的崩溃进行分段，这两个系统在它们所观察的内容上略有不同。
核心应用程序的崩溃率，我试图监控的破坏浏览器的神奇 WASM WebGL 部分，一直保持水平。相对静态的 HTML 营销页面的崩溃率上升了！营销页面，正如我所记得的那样，有一些滚动的 CSS 动画在今天的营销页面上很常见，显然那里的一些变化导致低端浏览器崩溃。
从中我吸取了一个重要的教训：即使您的应用程序没有突破浏览器的界限，监控崩溃也可能是值得的。阅读此概述以开始使用；我相信这就像提供default端点并在那里接受 POST 一样简单。
原文： https://neugierig.org/software/blog/2023/01/browser-crashes.html