直接回答：Worker 的唯一价值是把 CPU 密集计算移出主线程，保住 UI 的 60fps：大数据解析（CSV、日志文件）、图像处理（滤镜、压缩）、加解密与哈希、文本搜索索引构建（FlexSearch 类）、AI 推理（ONNX/WebGPU）。凡是 IO 型、DOM 型任务都不适合——Worker 里摸不到 DOM，通信又是异步的，滥用反而更慢更复杂。
展开解析：通信成本是决策关键：postMessage 默认走结构化克隆，对象越大序列化越贵（百 MB 级数据克隆一次几百毫秒，比计算本身还贵）；优化手段是 Transferable——ArrayBuffer、OffscreenCanvas 转移所有权零拷贝，传完发送方即失效；SharedArrayBuffer 加 Atomics 可共享内存（需要 cross-origin isolation 响应头，且回炉过 Spectre 安全审查）。工程实践：Worker 脚本打包用 Vite/webpack 的原生 worker 支持（new Worker(new URL(...))），comlink 把 postMessage 包装成 RPC 调用大幅改善开发体验；Worker 池复用（创建有启动开销，几毫秒到几十毫秒）；频繁小消息要批处理合并。收益验证：把主线程长任务（Long Tasks、INP 指标）在接入前后对比， Worker 化后 INP 应有显著改善，否则就是选错了场景。新兴替代： OffscreenCanvas（Worker 里渲染）、Worklet（渲染管线挂钩）各覆盖一部分场景，选型时一并评估。
追问方向：Transferable 与结构化克隆的边界？Worker 里如何调试与做错误监控？
（约 480 字）