断点续传的核心是记录已上传块的偏移量、大小和完成状态并持久化，结合按序分块读写与原子状态更新，辅以校验、防覆盖、超时清理等机制保障可靠性。
断点续传的核心不是“重传整个文件”，而是“记住传到哪了，从那里接着写”。捕获块（即记录已成功上传的文件块信息）是状态保存的关键动作，它和循环分块写入共同构成可靠传输的基础逻辑。
捕获块的本质是记录偏移与完成标记
每次成功写入一个数据块后，必须立即持久化该块的元信息：起始字节偏移量（offset）、长度（size）、是否完成（isUploaded）。不能只靠内存变量或临时文件名推断——中断后进程重启，这些信息就丢失了。
- 推荐用轻量结构存储，例如 JSON 文件：
{"file_id":"abc123","offset":4194304,"size":1048576,"isUploaded":true} - 数据库更稳妥，尤其在分布式场景下；单机可选本地文件，但需保证写入原子性（如先写临时文件 + rename）
- 避免用文件存在与否判断是否完成——上传中途崩溃可能留下大小不全的残块，直接跳过会导致最终文件损坏
循环分块写入要严格按偏移顺序推进
读取和写入必须解耦：读取靠 RandomAccessFile 或 FileChannel 定位 offset，写入靠独立输出流追加或覆盖。不能依赖“第 N 次循环就写第 N 块”这种隐式顺序。
- 每次循环前查状态，获取下一个待传的 offset（如
getLastUploadedOffset() + blockSize） - 读取时显式 seek 到该 offset，再读指定长度；若剩余不足，按实际字节数处理
- 写入成功后，立刻更新状态（如写入数据库 or 写入 JSON 文件），再进入下一轮
- 示例关键逻辑：
while (offset
状态保存与写入需协同防错
光有状态记录不够，写入过程本身也得容错。比如合并阶段若直接用 os.Write 循环写分块，偏移计算出错或未校验返回字节数，就会导致文件中间缺数据。
- 合并时优先用
io.Copy，它自动处理 buffer 复用和 partial write，但要求源支持Seek(0, io.SeekStart) - 目标文件打开时禁用
O_TRUNC，防止合并中断清空已有内容；完成后才设权限 - 每个分块文件写入前，用
os.O_CREATE | os.O_EXCL确保不覆盖已有块，避免并发冲突 - 服务端收到块后，建议校验客户端传来的 chunk MD5，再落盘，防止网络篡改或截断
清理机制是状态保存的闭环环节
状态存下来了，但没人管就变成僵尸数据。必须配套超时清理策略，否则磁盘迟早被临时块占满。
- 为每个上传会话生成唯一 ID（如 UUID），所有块和状态都绑定该 ID
- 临时目录路径带会话 ID，如
/tmp/upload_abc123/，便于隔离和批量清理 - 定期扫描
/tmp/upload_*/下最后修改超 24 小时的目录，递归删除 - 前端也应配合：页面关闭前调接口标记上传取消，或 localStorage 记录会话 ID，刷新后主动查询服务端状态
