直接用文件哈希做分片校验会出问题，因跨网络多客户端下存在哈希不可复现和块边界漂移两大风险：同一文件重试切块导致偏移错位，或读取不精确使字节流不同而哈希不一致；可靠方案是用文件名、大小与块索引组合生成幂等id（如base64(sha256(filename+size+index))）作为唯一标识，服务端据此查存而非依赖动态哈希。
为什么直接用文件哈希做分块校验会出问题
大文件分块同步时，很多人第一反应是「每个块算一次 sha256，服务端比对哈希值决定是否跳过」。这在单机本地场景可行，但跨网络、多客户端并发时，会踩两个坑：哈希计算不可复现 和 块边界漂移。
比如客户端 A 上传到第 3 块时断连，重试时若重新切块（例如按 4MB 固定大小），而服务端上次只存了前 2 块的哈希，新请求的第 1 块哈希和旧第 1 块一致，但后续块全部错位——因为起始偏移变了。更隐蔽的是，如果客户端用 io.CopyN 读取时没清空缓冲区或读取长度不精确，同一块数据可能被读出不同字节流，导致哈希不一致。
真正可靠的方案是：块标识必须由「全局唯一且稳定」的元信息生成，而不是运行时动态计算结果。
用块索引 + 文件指纹组合生成幂等 ID
核心思路是把「哪一块」和「属于哪个文件」绑定成不可篡改的 ID，服务端只认这个 ID，不依赖内容哈希。推荐结构：base64(sha256(filename + file_size + block_index))。
-
filename和file_size构成文件指纹，防止同名不同文件或截断文件误判 -
block_index从 0 开始整数，固定步长（如每块 5MB），不依赖实际读取长度 - 客户端和服务端用同一套分块逻辑（比如都用
math.Floor(float64(offset)/chunkSize)算索引），避免四舍五入差异 - 服务端收到上传请求时，先解析出该 ID，查数据库或 Redis 是否已存在；存在则直接返回 success，不写磁盘
示例：文件 report.zip 大小 12345678 字节，第 2 块（索引=1）的 ID 计算为：base64(sha256("report.zip" + "12345678" + "1"))，无论哪次上传、哪个客户端、哪台机器，结果都一样。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
如何让上传请求本身具备幂等性
HTTP 层必须配合，否则服务端再严谨，重复请求也会触发多次处理。关键点不是加 token，而是利用请求体特征做天然去重。
- 客户端在请求头带
X-Block-ID:，服务端用它当 Redis key 做 setnx（带过期时间，比如 1 小时） - 不要用
Content-MD5或Content-SHA256—— 这些 header 在 HTTP/2 分帧传输中可能被代理截断或重组，不可靠 - 上传 body 必须是原始二进制块，禁止 gzip 编码；否则同样数据压缩后哈希不同，且服务端解压失败概率高
- 如果用 multipart，必须确保 boundary 不随请求变化（有些库自动生成随机 boundary），否则同一块每次请求的 body 字节流都不同
Go 实现里，用 http.Request.Body 直接读取原始字节流，别走 ParseMultipartForm——那是给表单设计的，不是给二进制块的。
服务端存储层怎么避免“已接收但未落盘”的状态丢失
最常被忽略的环节：块上传成功后，服务端标记“已接收”，但还没来得及写入最终存储（比如合并成完整文件），进程崩溃了。重启后客户端重试，服务端查不到记录，又写一遍，导致块重复。
解决方案是引入两阶段状态：「received」和「committed」。
- 上传完成立刻写 DB 记录：
block_id、status="received"、uploaded_at、storage_path（临时路径，如/tmp/upload_abc123_part2） - 合并任务（比如所有块收齐后触发）只操作
status="received"的块，并在写入最终位置后，用事务更新 status 为"committed" - 服务启动时扫描所有
status="received"的块，检查对应storage_path文件是否存在且大小匹配；若存在，说明上次中断前已落盘，直接补 commit；若不存在，说明写入失败，删记录，让客户端重传
这个检查逻辑不能只靠定时任务——必须在每次上传请求进来时也顺手做一次（轻量级），否则刚崩溃完就来新请求，可能错过恢复窗口。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
