Web Worker 实现图片压缩多线程的核心是主线程负责交互与调度，Worker 承担像素级操作；需用 ArrayBuffer 零拷贝传输、createImageBitmap 解析、canvas.toBlob 输出，并依硬件并发数控制 Worker 数量及生命周期。
在图片压缩这类计算密集型任务中，用 Web Worker 实现多线程并发，核心是把压缩逻辑从主线程剥离，交由独立线程并行执行，避免阻塞 UI。关键不在“开多少线程”，而在于合理拆分、通信清晰、资源可控。
明确主线程和 Worker 的分工
主线程只负责用户交互、文件读取、结果展示和上传调度；所有像素级操作（解码、缩放、重编码）必须放在 Worker 里。Worker 不能访问 DOM 或 File 对象本身，所以主线程需提前将图片转为可传输格式：
- 推荐用
FileReader.readAsArrayBuffer()读取原始二进制，再通过postMessage(..., [arrayBuffer])使用 Transferable Objects 零拷贝传递，大幅提升大图性能 - 避免直接传 Base64 字符串——体积膨胀约 33%，序列化开销大，易触发内存警告
- 若需多图并发压缩，主线程可创建多个 Worker 实例，或复用单个 Worker 分批处理（更省内存）
Worker 内部实现高效压缩逻辑
Worker 脚本中不依赖 Canvas（部分环境受限），应优先使用原生图像 API：
- 用
createImageBitmap(file)异步解析图片，支持 WebP/AVIF 等现代格式 - 调用
canvas.getContext('2d').drawImage()缩放时，注意设置imageSmoothingQuality = 'high'并预设 canvas 尺寸，避免重排 - 压缩后用
canvas.toBlob(callback, type, quality)直接输出二进制，比 toDataURL 更省内存 - 对批量图片，可用
Promise.all(图片数组.map(compressOne))并行处理，但注意浏览器对并发解码的限制（通常 4–8 个）
控制并发数量与生命周期
盲目开多个 Worker 反而降低效率，需结合设备能力动态调整：
立即学习“Java免费学习笔记（深入）”；
- 用
navigator.hardwareConcurrency获取逻辑 CPU 核心数，作为最大 Worker 数参考（通常设为Math.min(4, hardwareConcurrency)） - 每个 Worker 完成任务后主动调用
self.close()；主线程在收到结果后调用worker.terminate()，防止泄漏 - 对超大图（如 >10MB），可在 Worker 中加进度反馈：
self.postMessage({ type: 'progress', index, percent: 65 })，方便主线程显示加载状态
实际压缩参数与质量权衡
压缩不是越小越好，要在体积、画质、耗时间找平衡点：
- JPEG：quality 设为 0.7–0.85，兼顾清晰度与体积；启用
mozJpeg或sharpWASM 版本可进一步优化 - WebP：quality 0.6–0.75，体积比 JPEG 小 25–30%，现代浏览器全覆盖
- 避免在 Worker 中做无意义重采样——先用
imageBitmap.width/height判断是否超目标尺寸，再决定是否缩放
