大文件分片上传内存优化需坚持“按需处理、及时释放、避免拷贝、分离线程”：①直接用file.slice()返回Blob传入FormData，禁用全量arrayBuffer读取；②并发数限3–6，用Promise池管理并及时清理FormData；③哈希计算移至Web Worker流式处理；④进度跟踪仅存轻量元数据，不缓存Blob。
大文件分片上传时内存占用过高，主要源于一次性读取、缓存未释放、Blob 复制冗余或主线程阻塞。优化核心是“按需处理、及时释放、避免拷贝、分离线程”。
避免全量读取与 Blob 冗余创建
File 对象本身是只读引用，不占额外内存；但调用 file.slice() 后若立即转为 Blob 或 ArrayBuffer，尤其在并发上传中反复构造，会触发内存复制。应直接使用 File.slice() 返回的 Blob 作为 FormData.append() 的参数，不主动 readAsArrayBuffer 或 new Blob() 封装。
- ✅ 正确：直接传
file.slice(start, end)给 FormData - ❌ 避免：先
await file.arrayBuffer()再切片 —— 这会把整个文件加载进内存 - ⚠️ 注意：
file.slice()是浅引用，不复制数据，内存开销极小
控制并发数并复用请求资源
并发上传过多分片，会导致大量 fetch 实例、FormData 对象和网络缓冲区同时驻留内存。建议将并发数限制在 3–6（参考 navigator.hardwareConcurrency || 4），并使用队列 + Promise 池管理，避免堆积。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用
Promise.allSettled(chunks.map(...).slice(0, maxConcurrent))控制批次 - 每个上传完成即
formData.delete('chunk')（虽非强制，但显式清理更可控） - 避免在闭包中长期持有
file或大chunk引用，上传回调结束后尽快让其脱离作用域
用 Web Worker 处理哈希计算与元信息生成
计算文件哈希（如 SHA-256）常需读取全文件流，若在主线程用 FileReader + async 分块读取，易造成长时间阻塞与 ArrayBuffer 缓存累积。移至 Web Worker 中执行可完全规避主线程内存压力，且 Worker 内存独立、任务结束即回收。
立即学习“Java免费学习笔记（深入）”；
- 主线程仅传递
file.name、file.size、file.lastModified等轻量信息用于生成临时 ID - 真实哈希计算由 Worker 流式读取并分块哈希，不缓存整文件
- Worker 完成后只回传哈希字符串，不传任何二进制数据
进度跟踪不依赖内存缓存分片内容
精准进度条常误用“已上传字节数 = 已完成分片数 × 分片大小 + 当前分片上传进度 × 分片大小”，这本身无内存问题；但若为支持刷新恢复而把所有分片 Blob 存入 localStorage 或全局数组，则严重浪费内存。
- ✅ 推荐：仅存轻量元数据 ——
{ hash, filename, totalChunks, uploaded: [0,2,5] } - ✅ 刷新后重新调用
file.slice()获取所需分片，不缓存 Blob - ❌ 不要将
chunks = [...]整个数组长期保留在内存中
