断点续传的核心是记录已上传块的偏移量、大小和完成状态并持久化，结合按序分块读写与原子状态更新，辅以校验、防覆盖、超时清理等机制保障可靠性。

断点续传的核心不是“重传整个文件”，而是“记住传到哪了，从那里接着写”。捕获块（即记录已成功上传的文件块信息）是状态保存的关键动作，它和循环分块写入共同构成可靠传输的基础逻辑。

捕获块的本质是记录偏移与完成标记

每次成功写入一个数据块后，必须立即持久化该块的元信息：起始字节偏移量（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 < fileSize) { byte[] chunk = readFileChunk(path, offset, 1024*1024); if (upload(chunk, offset)) { updateStatus(offset, true); offset += chunk.length; } else break; }

状态保存与写入需协同防错

光有状态记录不够，写入过程本身也得容错。比如合并阶段若直接用 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，刷新后主动查询服务端状态