Service Worker 本身不直接支持文件下载、分片或断点续传，但可作为网络代理层配合 Fetch API、Blob、IndexedDB 等实现大文件切片下载与并行断点续传；前端管理切片、并发、校验与恢复，SW 拦截缓存各分片以提升离线可用性与复用效率。
Service Worker 本身不直接支持文件下载、分片或断点续传，但它可以作为网络请求的智能代理层，配合前端逻辑（如 Fetch API、Blob、IndexedDB 和 File System Access API）实现大文件切片下载与并行断点续传。关键在于：将下载控制权交由页面 JS 管理切片、并发、校验和恢复，再通过 Service Worker 拦截并缓存各分片响应，提升离线可用性与复用效率。
分片策略与并发控制
将大文件按固定大小（如 2MB/片）切分为多个 Range 请求，避免单请求超时或内存溢出。前端需维护下载状态（已下、待下、失败），支持动态调整并发数（通常 3–6 路较稳妥）。
- 使用 fetch(..., { headers: { Range: 'bytes=0-2097151' } }) 发起分片请求
- 每个分片响应用 Response.arrayBuffer() 获取二进制数据，暂存于内存或写入 IndexedDB
- 失败分片自动重试（带退避），跳过已成功下载的 Range
断点续传状态持久化
下载进度不能仅存在内存中。必须将每个分片的完成状态、起始偏移、长度、ETag（或 Content-MD5）持久化存储。
- 推荐用 IndexedDB 存储结构化元数据：{ url, fileId, offset, length, status: 'done'|'pending'|'error', etag }
- 首次下载前先查询 DB，合并已存分片信息，生成剩余待下载 Range 列表
- 避免依赖 localStorage——容量小、阻塞主线程、不支持二进制
Service Worker 的核心作用：透明缓存与离线代理
SW 不负责调度下载，但可拦截分片请求，将其缓存到 Cache Storage，并在后续请求中直接返回，加快恢复速度、节省带宽。
- 在 SW 的 fetch 事件中匹配分片 URL（如包含 /download?file=id&range=）
- 命中缓存则直接 return response.clone()；未命中则 fetch 后 put 进 cache
- 注意设置 Cache-Control 或手动管理缓存生命周期，防止脏数据
组装与还原文件
所有分片下载完成后，需按 offset 顺序拼接为完整文件。浏览器不支持直接写磁盘，但可通过 Blob + URL.createObjectURL 提供下载，或使用 File System Access API 写入用户本地目录（需用户授权）。
- 从 IndexedDB 读取全部分片 ArrayBuffer，按 offset 排序后用 new Blob(parts, { type: mimeType })
- 调用 showSaveFilePicker()（现代浏览器）获取文件句柄，再用 createWritable() 流式写入
- 若需校验完整性，可在下载前请求服务端提供整个文件的 SHA256，在拼接后比对
