这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
合并与校验策略
合并：分片到齐后的最后一步
所有分片上齐后，服务端把它们合并成完整文件。合并方式取决于存储：
- 本地磁盘：按分片编号顺序合并写入一个文件。
- 对象存储：提前适配对象存储的 multipart 能力，让分片直接进入对象存储，由对象存储完成合并（省去业务侧搬运）。
无论哪种，合并前都要做完整校验。
合并前必须检查
| 检查项 | 目的 |
|---|---|
| 分片数量是否完整 | 防止缺片 |
| 每个分片大小是否符合预期 | 防止大小不一致 |
| 每个分片 hash 是否正确 | 防止分片被篡改 / 传错 |
| 最终文件 hash 是否与初始化任务一致 | 防止合并出错 / 内容被换 |
服务端不能完全信任客户端：客户端报的 hash 只是参考，合并后必须用服务端算出的整体 hash 校验。
合并的异步化
大文件合并很耗时，不应阻塞在同步请求里。推荐状态流转：
uploading -> merging -> scanning -> availablemerging：合并任务在后台执行，客户端轮询或等回调。scanning：合并完成后进入安全扫描（第 7 章）。available：扫描通过，文件可访问。
用户界面应该展示「正在合并」「正在校验」而不是一个模糊的 100%。
临时分片的清理
分片上传引入一个必须处理的问题：未完成任务留下的临时分片。
- 每个任务设过期时间（如 24 小时）。
- 后台定时任务清理超时未完成的任务和分片。
- 用户放弃上传、上传失败，都要有清理入口。
否则临时分片会悄悄堆积，存储成本失控。
一句话总结
分片上传把「大文件一次传」变成「小任务并行传 + 严格校验 + 后台合并」，成功率大幅提升；代价是状态、并发、清理都要管理好。
下一章看分片之上更贴近用户体验的一层：断点续传。
发现内容有问题？
告诉我们哪里需要改进。