web worker 无原生超时取消机制，需协作式检查：主线程传入 deadline 时间戳，worker 在循环/递归中主动比对 date.now() 并提前退出；terminate() 会立即销毁线程，不可恢复；abortsignal 仅限 fetch 且需 transfer 传递。
Web Worker 里没有原生 setTimeout 超时取消机制
Web Worker 是独立线程，但本身不提供类似 AbortController 这类可中断的异步原语（直到近年部分浏览器才在 fetch 中支持 signal）。你无法像主线程那样对一个正在跑的 postMessage 或计算任务“喊停”。所谓“超时取消”，本质是靠协作式检查 + 提前退出。
- Worker 内部必须主动轮询或拆分任务，在关键节点检查是否已超时
- 主线程不能强制终止 Worker，只能调用
worker.terminate()—— 这会立刻销毁整个线程，所有中间状态丢失 - 如果任务是纯计算（比如大数组排序、加密哈希），没有 I/O 或
await点，就根本没法插入检查逻辑
用 self.postMessage() + 时间戳做协作式超时判断
最轻量、兼容性最好的做法：主线程发任务时附带截止时间戳，Worker 每次循环/递归/分块处理前比对当前时间。这不是“中断”，而是“不继续”。
- 主线程发送：
worker.postMessage({ data: hugeArray, deadline: Date.now() + 3000 }) - Worker 内部在 for 循环中加判断：
if (Date.now() > msg.deadline) { self.postMessage({ status: 'timeout' }); return; } - 注意不要用
performance.now()和Date.now()混用——Worker 和主线程的performance.timeOrigin可能不同，跨线程只认Date.now() - 对递归算法，把
deadline作为参数透传下去，避免闭包捕获过期值
worker.terminate() 不等于“取消任务”，而是“杀进程”
调用 worker.terminate() 后，Worker 线程立即停止执行，所有定时器、fetch、importScripts 全部中断，且不会触发 onerror 或 onmessage。它适合防呆，不适合精细控制。
- 适用场景：用户点击“取消”且你确认后续无需任何结果（比如放弃上传预处理）
- 不适用场景：需要返回部分结果、清理资源、记录进度 —— 因为 terminate 后 Worker 无机会执行任何代码
- 调用后记得置空引用：
worker = NULL，否则可能引发内存泄漏或重复调用报错"Failed to execute 'postMessage' on 'Worker': Worker is either in terminated or closing state"
chrome 120+ 支持 AbortSignal 传入 fetch，但仅限网络请求
如果你的 Worker 任务主要是调用 fetch（比如批量拉取 API），可以利用新版支持：fetch(url, { signal })。但 signal 必须由主线程创建并传入，且只对 fetch 生效。
立即学习“前端免费学习笔记（深入）”；
- 主线程：
const ac = new AbortController(); setTimeout(() => ac.abort(), 5000); worker.postMessage({ url, signal: ac.signal }, [ac.signal]); - Worker 中：
fetch(url, { signal }).catch(err => { if (err.name === 'AbortError') self.postMessage('aborted'); }); - ⚠️ 注意：
AbortSignal无法序列化，必须用transfer机制传入（即第二个参数带[ac.signal]），否则报错"DataCloneError: function is not transferable" - 纯计算任务依然不受控 —— 这个 signal 对
for循环、json.parse等完全无效
主线程和 Worker 的时间感知、错误传播、资源生命周期都不对等，所谓“超时控制”其实是两套逻辑在各自边界内尽力配合。真正难的不是写几行代码，而是想清楚：这个超时，到底要保结果，还是保响应，还是保稳定？选错方向，后面全是坑。