Chrome页面闪退主因是渲染进程异常终止，包括GPU崩溃、内存超限、WebGL上下文丢失、音视频解码卡死等；需通过chrome://crashes、Console报错、chrome://gpu及Memory面板定位，并针对性处理自动播放策略、资源泄漏与Worker错误。
Chrome 页面崩溃常见原因与定位方式
Chrome 中 HTML5 页面闪退，通常不是“随机崩溃”，而是触发了渲染进程异常终止（如 GPU 崩溃、内存超限、WebGL 上下文丢失、音视频解码器卡死等）。最直接的判断方式是打开 chrome://crashes 查看最近崩溃报告，或在开发者工具 Console 中留意类似 Uncaught (in promise) DOMException: The play() request was interrupted 或 GPU process crashed 的提示。
- 若页面含大量
<canvas>绘图或 WebRTC/Video 尝试自动播放，优先检查 GPU 加速是否被禁用或驱动不兼容 - 使用
chrome://gpu确认Graphics Feature Status中各项是否为enabled，尤其关注Canvas、WebGL、Rasterization - 启动 Chrome 时加参数
--disable-gpu --disable-software-rasterizer可临时验证是否为 GPU 相关问题（但会牺牲性能）
HTML5 自动播放策略导致的“假闪退”
Chrome 77+ 强制执行 Autoplay Policy：无用户手势（click/tap）前提下，带声音的 <video> 或 <audio> 调用 play() 会立即 reject Promise，并可能引发后续逻辑中断（如未 catch 的 Promise rejection 导致脚本静默失败，页面交互失活，误以为“闪退”）。
video.play().catch(e => {
console.warn("Autoplay prevented:", e);
// 此处必须 fallback，例如显示播放按钮或静音后重试
video.muted = true;
video.play().catch(e2 => console.error("Even muted failed:", e2));
});
- 永远对
video.play()和audio.play()做.catch()处理，不能忽略返回的 Promise - 避免在
DOMContentLoaded或load事件中直接调用带声播放；改用用户点击后首次触发 - 若需静音自动播放，务必在
play()前设置video.muted = true且video.volume = 0（部分版本需两者兼备）
内存泄漏与 Canvas/WebGL 资源未释放
频繁创建 <canvas>、WebGLRenderingContext、AudioContext 或未清理 requestAnimationFrame 回调，会导致 Chrome 渲染进程内存持续增长，最终被系统或 Chrome 主动 kill（表现为白屏、DevTools 断连、Console 无报错）。
- 每次销毁 canvas 元素前，手动调用
canvas.getContext('2d').reset()（如有）并置空引用 - WebGL 场景中，显式调用
gl.deleteTexture()、gl.deleteBuffer()等释放资源，不要依赖 GC - 用
performance.memory（需开启--enable-precise-memory-info启动参数）或 Chrome DevTools 的 Memory 面板定期快照比对 -
requestAnimationFrame必须配对cancelAnimationFrame(id)，尤其在组件卸载、tab 切换时
Web Workers 与跨域 iframe 引发的静默崩溃
Chrome 对 Worker 线程错误容忍度极低：一个未捕获的 error 事件（如 onerror 未监听）或 SharedArrayBuffer 初始化失败（缺少 crossOriginIsolated），会导致整个 Worker 进程退出，若主线程依赖其响应，可能表现为功能失效或页面卡死。
立即学习“前端免费学习笔记（深入）”；
// 主线程中启动 Worker 必须监听 error
const worker = new Worker('worker.js');
worker.onerror = e => {
console.error("Worker crashed:", e.filename, e.lineno, e.message);
// 此处应降级逻辑，而非忽略
};
// worker.js 中也需 try/catch 全局逻辑
self.onmessage = e => {
try {
// heavy computation
} catch (err) {
self.postMessage({ error: err.toString() });
}
};
- 含
SharedArrayBuffer的页面必须同时满足：COOP: same-origin+COEP: require-corp响应头，否则 Worker 初始化即失败 - 第三方 iframe（如广告、统计 SDK）若自身存在内存泄漏或无限 loop，也可能拖垮主页面；可用
chrome://sandbox查看各 frame 的 sandbox 状态 - 避免在 Worker 中使用
console.log输出大量数据——某些 Chrome 版本下会因 IPC 缓冲区满而卡死
chrome://crashes、chrome://gpu 和 Memory 面板的堆快照差异。 
