分片上传通过并发上传、单片重传和合理分片大小（5MB～20MB）提升超大文件传输效率。它支持断点续传与指纹校验，实现失败隔离、进度可溯和带宽高效利用。
分片上传能显著提升超大文件的传输效率，核心在于“并发+容错+可控”。它不是单纯把文件切开，而是通过并行处理、失败隔离和进度可溯，把上传从单线程阻塞变成多任务协同。
用并发上传榨干带宽
分片后各块可独立发起 HTTP 请求，客户端默认支持 5 路并发（可调），实际吞吐接近带宽上限。比如 10G 文件切成 10MB/片，1024 片可同时调度，网络空闲时间大幅减少。但并发数并非越高越好——超过本地 CPU 或网络连接数限制反而会拖慢整体速度，建议根据设备性能和链路稳定性在 3～10 之间微调。
失败只重传一块，不回滚全部
单个分片上传失败（如超时、校验不通过、连接中断），OSS 会保留已成功上传的分片记录，下次只需补传失败的那一块。不需要重新读取整个文件、也不用重走鉴权和初始化流程。这对 10G+ 文件尤其关键：传到 98% 断网，只需重传最后几片，而非再耗几十分钟从头开始。
合理设置分片大小，平衡开销与粒度
推荐分片大小设在 5MB～20MB 区间：
- 小于 5MB：HTTP 请求数量激增，TCP 握手、TLS 协商、请求头开销占比升高，整体效率下降；
- 大于 20MB：单片上传耗时变长，失败后重传成本上升，且内存占用更高（尤其前端需流式读取）；
- OSS 官方建议 100KB～5GB 每片，但生产环境普遍选 10MB 左右，兼顾速度、稳定性和服务端压力。
配合断点续传与指纹校验，实现真正可靠
上传前计算文件整体哈希（如 SHA-256），作为唯一指纹；上传过程中将 uploadId 和已成功分片序号存入 localStorage 或 Redis。续传时先用指纹查后端，直接获取缺失分片列表，跳过已传部分。这样即使页面刷新、浏览器崩溃、网络反复中断，都能精准接续，无需猜测或全量重试。
