go分片上传需手动实现客户端切片与服务端合并，核心是避免内存暴增（用io.readat按偏移读）、保证顺序完整性（校验索引与哈希）、磁盘暂存分片、严格按序合并并验证最终文件哈希。
Go 语言本身不内置分片上传逻辑，必须自己实现客户端切片 + 服务端合并，且关键在于「避免内存暴增」和「保证顺序/完整性」。
如何用 io.ReadAt 安全读取大文件的某一片段
直接 os.ReadFile 会把整个文件加载进内存，1GB 文件就占 1GB RAM —— 绝对不能这么做。正确做法是打开文件后，用 io.ReadAt 或 *os.File.ReadAt 按偏移量读指定长度的字节块。
-
ReadAt是线程安全的，多个 goroutine 可并发读不同 offset，无需加锁 - 注意：返回的
n可能小于请求长度（如读到文件末尾），必须检查n == expectedSize || err == io.EOF - 不要用
bufio.Reader包裹文件句柄再调ReadAt—— 它不支持随机读，会破坏 offset
示例片段：
f, _ := os.Open("big.zip")
defer f.Close()
buf := make([]byte, 5*1024*1024) // 5MB 片
n, err := f.ReadAt(buf[:], int64(pieceIndex)*5*1024*1024)
if err != nil && err != io.EOF {
// 处理错误
}
data := buf[:n]
服务端如何接收并暂存分片而不阻塞或丢失
HTTP 请求体默认是流式读取，但分片上传要求「每个请求只写入对应 offset 的数据块」，不能简单用 io.Copy 直接写磁盘——否则无法保证写入位置，也难以校验。
- 接收时用
r.Body流式读，配合io.MultiWriter同时写入临时文件 + 计算sha256校验和 - 分片元信息（如
filename、chunkIndex、totalChunks、checksum）必须通过 URL query 或 header 传，**不能放 body 里混淆二进制数据** - 临时文件建议按
{upload_id}/{chunk_index}路径存储，避免单目录下文件过多影响性能 - 别用内存 map 缓存所有分片 —— 上传中断时会丢，且容易 OOM；用磁盘暂存才是可靠做法
如何合并分片并校验最终文件完整性
合并不是简单 cat a b c > final，必须严格按序、无跳片、无重复，且最后要验证整体哈希是否匹配客户端声明的 final_hash。
- 先检查本地是否存在全部
0..N-1分片文件，缺任一片就返回 400 错误 - 用
os.OpenFile以os.O_CREATE|os.O_WRONLY|os.O_TRUNC打开目标文件，再用io.Copy逐个os.Open分片文件追加 - 合并完成后，重新
os.Open最终文件，用sha256.New()+io.Copy计算总哈希，与客户端提交的X-Final-SHA256header 对比 - 若校验失败，立刻删掉最终文件和所有分片 —— 留着脏数据比报错更危险
为什么不用第三方库（如 tus）反而更可控
tus 协议虽标准，但 Go 生态中成熟 server 实现（如 tusd）依赖 SQLite 或 Redis 做元数据存储，部署复杂度陡增；而自研方案只要求一个可写的磁盘路径。
- 业务若需定制策略（如分片大小随网络动态调整、对接对象存储直传、权限绑定用户 ID），tus 的中间层反而成阻碍
- tus 的
Upload-Offset和Upload-Lengthheader 在 Nginx 反代下常被截断，调试成本高 - 真正难的不是协议解析，而是「断点续传时如何安全识别已传分片」—— 这必须结合业务唯一 ID（如
upload_id）+ 分片索引 + checksum 三者联合判断，通用库做不到这点
分片上传最易出问题的地方不在切或合，而在「客户端传错 index」「服务端没校验 checksum 就合并」「临时文件清理时机不对导致磁盘爆满」—— 这些都得靠明确的边界检查和防御性编码来兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
