Web Worker 不会因主线程崩溃而自动回收，而是持续运行直至页面卸载或浏览器强制清理；其生命周期独立于主线程，依赖页面上下文存活、引用计数及浏览器策略。

主线程崩溃时，Web Worker 不会“自动回收”——它通常继续运行，直到页面完全卸载或浏览器强制清理。这不是设计缺陷，而是机制使然：Worker 的生命周期不依赖主线程是否“健康”，而取决于页面上下文是否存活、是否有引用、以及浏览器自身的清理策略。

主线程崩溃 ≠ 页面卸载

主线程可能因未捕获异常、内存溢出或脚本中断而崩溃，但只要标签页没关闭、URL 没跳转、document 仍存在，浏览器就认为该页面上下文依然有效。此时 Dedicated Worker 仍驻留内存，线程持续占用 CPU 和堆空间，且无法被主线程控制（因为主线程已不可用）。

• 崩溃后 Worker 无法再收消息（postMessage 失败静默丢弃）
• Worker 内部的定时器、fetch、循环仍可能执行，甚至引发更多异常
• 没有浏览器标准规定“主线程挂了就杀掉它的 Worker”，行为由各引擎自行决定，不可预测

真正可靠的回收时机只有两个

Worker 的释放不靠“崩溃检测”，而靠底层环境变更：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 页面完全卸载：用户关闭标签页、刷新、导航到新地址 → 浏览器终止所有关联的 Dedicated Worker，并回收线程与内存（这是最确定的兜底）
• Shared Worker 引用归零：如果使用 Shared Worker，只要所有页面/iframe 都断开连接（包括崩溃页在内），引用计数为 0，浏览器才会销毁它

能做的主动防御措施

既然无法监听“主线程崩溃”，就应减少对它的依赖，把关键清理逻辑前移到更可控的节点：

立即学习“Java免费学习笔记（深入）”；

• 在 beforeunload 或 pagehide 中调用 worker.terminate() —— 这些事件即使主线程即将异常，也大概率能触发
• 对长时任务加超时保护：Worker 内部用 setTimeout 或 AbortSignal 设置最大执行时间，超时后调用 self.close()
• 避免 Worker 自行启动不可控异步操作（如无终止条件的 setInterval 或轮询），改用按需触发 + 明确结束信号
• 若 Worker 仅用于一次性计算，创建后立即发任务，收到结果后立刻 terminate()，不等待后续逻辑

崩溃场景下的现实建议

实际开发中，不应把 Worker 回收寄托于崩溃处理，而应默认它“可能残留”：

• 不要在 Worker 中持久写入全局状态（如 localStorage、IndexedDB）而不加清理标记
• 敏感计算（如加密、鉴权）避免在 Worker 中缓存密钥或 token，防止残留进程泄露信息
• 服务端可配合做心跳或 session 绑定，前端崩溃后服务端主动作废相关上下文