分片上传中断后通过服务端暴露/upload/status?upload_id=xxx接口返回已持久化的分片索引列表（如[0,1,2,4,5]），客户端据此识别断点（如缺失3）并续传；元数据须落盘且原子写入，推荐sqlite或带rename的json文件；并发时按upload_id加锁并条件插入防重复；合并阶段按序流式拼接、校验etag、失败中止，确保状态一致性。
分片上传中断后如何识别已上传的块
关键不是“重新上传”，而是让客户端和服务端对齐已成功写入的分片索引。服务端必须暴露一个接口（如 /upload/status?upload_id=xxx），返回已接收并持久化的分片列表，比如 [0,1,2,4,5] —— 注意中间缺失的 3 就是断点。客户端据此跳过已传块，从第 3 片开始续传。别依赖文件系统时间戳或大小判断，容易因网络重传、服务重启导致误判。
分片元数据该存在哪儿才可靠
不能只存内存或临时目录：upload_id 对应的分片状态必须落盘且具备原子性。推荐用轻量级方案：
• 用 SQLite 单文件，每条记录含 upload_id、chunk_index、etag（校验值）、created_at
• 或直接写 JSON 文件到 /data/uploads/{upload_id}/chunks.json，但每次写入需 os.Rename 替换旧文件，避免写一半崩溃
• Redis 可用，但必须开启 AOF + fsync 每秒，否则重启丢状态
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
如何防止同一分片被重复写入或覆盖
并发上传时，多个请求可能同时提交第 7 片。服务端要校验：先查 DB/JSON 是否已有该 chunk_index，有则直接返回 200；没有再写入。注意加锁粒度——按 upload_id 锁即可，别锁全局。更稳妥的做法是用条件插入：SQLite 的 INSERT OR IGNORE，或 PostgreSQL 的 ON CONFLICT DO NOTHING。别在写完文件后再更新元数据，否则文件写了但状态没记，恢复时就找不到它。
恢复上传时怎么合并分片不卡死
最终合并阶段最容易出问题。不要用 io.Copy 逐个 open+append，小分片多时 I/O 频繁且易出错。正确做法：
• 按 chunk_index 排序，打开所有分片文件（用 os.OpenFile 配 os.O_RDONLY）
• 用 io.MultiReader 拼接，再流式写入目标文件
• 合并前校验每个分片的 etag，缺一块或校验失败就中止，返回明确错误 "chunk 3 corrupted"
• 合并完成后立刻删分片目录，避免残留垃圾
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
