sessionstorage 不适合做大文件并发上传的片区标记，应改用 map + uploadid 管理分片状态，并通过 abortcontroller 统一控制请求；避免字符串 key，推荐结构化内存对象管理。
SessionStorage 本身不适合做大文件并发上传时的片区标记，因为它容量小（通常 5MB）、仅限当前标签页、且无法跨线程/Worker 访问，更不支持原子操作或监听变更。真正可行的方案是绕开 SessionStorage，改用更合适的机制来实现“单标签页内多分片上传的片区标记与协调”。
用 Map + 全局唯一 uploadId 管理分片状态
在页面初始化上传任务时，生成一个随机 uploadId（如 crypto.randomUUID()），作为本次上传会话的唯一标识。用 JavaScript 内存中的 Map 存储该 uploadId 下所有分片的状态（如 index、status、progress、blob 引用等）：
- 每个分片上传前，向 Map 中写入 { index: 0, status: 'pending', progress: 0 }
- 上传中更新 progress 和 status（'uploading' / 'success' / 'error'）
- 所有分片完成后再触发合并逻辑，避免依赖 Storage 同步
- 页面卸载前可选将关键状态序列化到 sessionStorage 作轻量恢复（非必需）
用 AbortController 统一控制同标签页所有分片请求
单个上传任务的所有 fetch 请求共享同一个 AbortController，便于用户点击“暂停”或关闭页面时中止全部进行中的分片：
- const abort = new AbortController()
- fetch(url, { method: 'POST', body: chunk, signal: abort.signal })
- abort.abort() → 所有挂载 signal 的请求立即 reject
- 无需轮询或标记位，天然满足“单页内协同”需求
避免用 SessionStorage 做实时状态同步
SessionStorage 不是响应式存储，无法监听变化，也无法保证写入顺序和并发安全：
- 多个分片同时调用 setItem 可能覆盖彼此（无锁、无事务）
- 不同 Worker 或 iframe 无法读取主页面的 sessionStorage
- 即使只在主线程用，频繁读写也带来性能损耗和 JSON 序列化风险
- 真需要持久化中间状态（如断点续传），应存到 IndexedDB 或后端记录，而非 sessionStorage
片区标记建议用结构化内存对象，而非字符串键
不要拼接类似 "upload_abc123_chunk_5_status" 这样的 sessionStorage key。直接用嵌套对象管理：
const uploads = new Map();
uploads.set('abc123', {
total: 12,
chunks: [
{ index: 0, status: 'success', size: 2097152 },
{ index: 1, status: 'uploading', progress: 0.65 },
{ index: 2, status: 'pending' }
]
});
这样可直接遍历、过滤、更新，逻辑清晰，无序列化开销，也规避了 key 冲突和解析错误。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
