web worker 中 settimeout/setinterval 受后台节流影响，需用 date.now() 校准并结合 page visibility api 协同；fetch 可直接使用但需手动实现超时与限流，所有环境感知依赖主线程 postmessage 同步。
Web Worker 内部可以正常使用 setTimeout、setInterval 和 fetch，但必须清楚它们的行为边界和常见限制——不是“能不能用”，而是“怎么用才可靠”。
定时器在 Worker 中的表现与注意事项
Worker 支持标准定时器 API，但受浏览器后台节流影响：标签页切到后台后，setTimeout 和 setInterval 可能被大幅延迟（如最小间隔拉长至 1s 甚至暂停），这不是 Bug，而是浏览器节能策略。
- 不要依赖
setInterval(fn, 1000)实现精确秒级调度；它在后台会失准 - 若需逻辑时间连续性（如倒计时、心跳），应结合
Page Visibility API由主线程通知挂起/恢复状态，并在 Worker 内累计暂停时长，用Date.now()主动校准触发时机 - 避免嵌套或长链
setTimeout，改用单次轮询 + 时间戳判断（例如每 50ms 检查一次“是否该执行下一轮”） -
performance.now()不推荐跨线程用于定时逻辑，因其起点（timeOrigin）与主线程不一致，且同样被后台节流
网络请求（fetch）的使用方式与增强控制
Worker 可直接调用 fetch 发起请求，支持 JSON、Blob、FormData 等常见类型，且不会阻塞主线程。但原生 fetch 不自带超时或中断能力，需主动设计。
- 基础用法与主线程一致：
fetch(url, { method: 'POST', body: JSON.stringify(data) }) - Chrome 120+ 支持将主线程创建的
AbortSignal通过postMessage传入 Worker，并在fetch中使用（需transfer传递）；但仅对 fetch 生效，不作用于计算或定时器 - 无 AbortSignal 时，可手动实现超时：在
fetch外层包裹Promise.race([fetch(), new Promise(...)])，并在 Worker 内检查Date.now()是否超限 - 批量请求建议加限流控制（如每秒最多 3 次），用时间窗口数组或令牌桶逻辑管理，避免触发服务端 429
通信协同是关键前提
Worker 无法访问 document、window 或页面可见性状态，所有环境感知都依赖主线程主动同步。
- 主线程监听
visibilitychange，通过postMessage向 Worker 发送{ type: 'pause', timestamp }或{ type: 'resume', timestamp } - 需要服务端时间校准时，主线程可定期发送
{ type: 'sync', serverTime, localTime }，Worker 根据往返差估算漂移并调整本地逻辑时钟 - 所有定时任务和请求的状态（如“正在重试第 2 次”“当前排队 3 个请求”）应通过
postMessage主动上报，让主线程可监控、可干预
不能做的事要提前避开
有些操作看似合理，实则无效或危险：
- 在 Worker 中尝试访问
localStorage、document.cookie或任何 DOM 相关 API —— 会直接报错 - 用
worker.terminate()当作“取消请求” —— 它会立即销毁整个线程，fetch 不会触发 reject，也不会执行 cleanup - 向 Worker 传大对象（如百 MB 图片 ArrayBuffer）却不使用
transfer参数 —— 导致主线程卡顿、内存暴涨 - 假设
setInterval在后台仍按设定频率执行 —— 实际可能几秒才触发一次，甚至完全跳过
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
