Worker 是前端并行压缩解压的核心，通过移出主线程保障 UI 流畅，结合 Compression Streams/WASM 实现流式处理，分块加载防 OOM，结构化分工与路径索引提升 ZIP 处理效率，并行调度需控粒度、让时机、防崩溃，配套缓存、校验、降级确保生产可用。
Worker 是实现前端并行压缩与解压的核心载体——它把 CPU 密集型任务移出主线程，避免 UI 卡顿，同时支持多线程调度与内存隔离。关键不在于“能不能做”，而在于“怎么分层协作、规避限制、保障稳定”。
压缩：Web Worker + Compression Streams 或 WASM
现代浏览器原生支持 CompressionStream（Chrome 107+、Firefox 113+），无需额外库即可完成 gzip/deflate 压缩：
- 在 Worker 中调用
file.slice().stream().pipeThrough(new CompressionStream('gzip'))，直接流式压缩分片，不落地、不拼接 - 对兼容性要求高的场景，改用
fflate（轻量、无依赖、支持同步/异步）或libdeflate-wasm（WASM 版本，性能提升 5–6 倍） - 避免在主线程预读整个文件；Worker 应使用
FileReader.readAsArrayBuffer分块加载（如每次 4MB），防止 OOM
解压：Worker 承载算法，主线程负责资源映射
JSZip 等纯 JS 解压器可在 Worker 运行，但 ZIP 解析本身是 I/O + CPU 双重压力，需结构化分工：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 主线程传入 Blob 或 ArrayBuffer，Worker 调用
JSZip.loadAsync()或fflate.unzip()解压，输出为{ filename: Uint8Array }映射表 - 若压缩包含目录结构（如
/assets/img/logo.png），Worker 需构建路径索引树，供后续请求按需查表返回 - 解压结果不直接构造 Response，而是通过
postMessage({ type: 'unpacked', files: map })回传；主线程按需生成 Blob URL 或注入 Service Worker 缓存
并行调度：控制粒度、让出时机、防崩溃
真正“并行”不是开一堆 Worker，而是合理切分任务并管理执行节奏：
立即学习“前端免费学习笔记（深入）”；
- 单个大型 ZIP 包不解成多个 Worker，而是在一个 Worker 内按文件粒度解压：每处理完 5–10 个文件，用
setTimeout(() => {}, 0)让出 JS 引擎控制权，防止长时间阻塞 - 多个独立压缩任务（如上传前的 3 个大附件）可分别分配给不同 Worker，用
Worker构造函数动态创建，完成后.terminate() - 监听
worker.onerror和内部try/catch，对 CRC 错误、manifest 缺失等明确上报，不静默失败
配套机制：缓存、校验、降级缺一不可
脱离工程上下文的解压只是玩具，生产级方案必须闭环：
- 解压后资源写入
Cache API时，使用专用 cache 名（如'unpacked-v1'），与原始压缩包缓存分离，便于独立清理 - 校验必须在 Worker 内完成：用
SubtleCrypto.digest('SHA-256', uint8array)对每个解压文件实时哈希，比对 manifest 中预置摘要 - 当 Worker 崩溃或浏览器不支持 WASM 时，自动降级为小文件主线程解压 +
requestIdleCallback分帧渲染，保证基础可用性
