fetch 在 web worker 中真正脱离主线程运行，不参与渲染、不触发重排重绘、不争抢事件循环，请求全流程在 worker 内独立完成，确保主线程稳定 60fps。
fetch 在 Web Worker 中能真正脱离主线程运行，不参与 UI 渲染循环，也不触发重排重绘。它不会占用主线程的事件循环，因此即便发起多个并发请求、处理大响应体或等待慢接口，也不会拖慢动画帧率或导致页面卡顿。
fetch 在 Worker 中是完全独立的网络执行环境
Worker 线程拥有自己的全局作用域（self），其中 fetch 是原生可用的 API，和主线程中行为一致但互不干扰：
- 请求发起、连接建立、响应接收、流式读取全部在 Worker 线程内完成
- 不共享主线程的 cookie、缓存策略（除非显式配置
credentials: 'include'且同源） - 不触发主线程的
beforeunload、visibilitychange等生命周期事件 - 即使 fetch 长时间 pending 或响应超大，主线程仍可稳定维持 60fps 渲染
与主线程 fetch 的关键差异点
这些差异直接决定了性能是否“被解放”：
- 无 DOM 关联开销：Worker 中 fetch 不会触发任何样式计算、布局、绘制流程，也无需维护 requestAnimationFrame 同步队列
- 无事件循环争抢：主线程忙于渲染或处理用户输入时，Worker 的 fetch 仍在后台推进，不排队、不等待
- 可批量发起而不影响交互：例如在 Worker 中并行 fetch 10 个配置项，主线程滚动、点击、输入完全不受影响
- 错误隔离：fetch 报错（如 CORS、网络中断、timeout）只在 Worker 内抛出，不会打断主线程 JS 执行流
如何验证 fetch 是否真正释放了主线程
可通过浏览器开发者工具实测确认：
- 打开 Performance 面板，录制一段含大量 fetch 请求的操作
- 观察主线程火焰图：Worker 中的 fetch 应完全不出现在主线程堆栈中，仅在 “Worker” 轨道下可见
- 检查 FPS 曲线：即使 fetch 响应耗时 800ms，FPS 仍应稳定在 60，无掉帧或抖动
- 在主线程中执行
performance.now()对比：连续调用间隔应始终 ≤16ms，不受 fetch 状态影响
实际使用中需注意的边界
虽能解放主线程，但并非“无感”使用：
- 数据传递仍依赖
postMessage，大响应体（如 JSON >2MB）序列化/反序列化有开销，建议分块或压缩传输 - redirect 默认为
manual，需显式设redirect: 'follow'否则会中断链路 - 不能用 IP 地址请求，只支持域名；端口固定为 80/443
- URL 总长度不能超过 4 KB，过长需改用 POST + body 传参
