不能用 io.ReadAll 读大文件，因其会将整个文件加载进内存导致 OOM；应使用 io.ReadAt 分片读取并配合 channel 传递结构化数据块，确保内存可控、并发安全与断点续传可靠。
为什么不能用 io.ReadAll 读大文件
直接调用 io.ReadAll 会把整个文件加载进内存，1GB 文件就占 1GB 堆空间，GC 压力陡增，服务可能被 OOM Kill。这不是“慢”，是根本不可行。
分片读取的核心目标不是“快”，而是“可控”：控制内存峰值、控制并发粒度、控制失败影响范围。通道在这里只负责传递数据块，不承担状态管理或调度逻辑。
- 每次读取建议用固定大小缓冲区，如
make([]byte, 4*1024*1024)（4MB），太大易挤占内存，太小则系统调用频繁 - 必须用
file.Seek(offset, io.SeekStart)显式定位，别依赖前一次Read的文件指针位置——并发 goroutine 之间不共享文件偏移 - 最后一块读取后，
n < len(buf)一定为真，上传或写入前务必截断：buf[:n]，否则可能带上次残留数据
用 chan []byte 分发分片数据的正确姿势
通道只是数据搬运工，不是任务调度器。常见错误是把“读第几块”“传给谁”“失败了怎么重试”全塞进通道里，结果逻辑耦合、调试困难、goroutine 泄漏。
推荐做法：一个 goroutine 专职按序读取并发送，多个 goroutine 专职消费，用 sync.WaitGroup 控制生命周期，用 context.Context 控制超时与取消。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 发送端不要往通道塞原始
[]byte，而应塞struct{ Data []byte; Offset int64; Index int }，消费端才能做顺序校验和断点识别 - 通道必须带缓冲，比如
make(chan Chunk, 4)，否则读写双方容易卡死；缓冲大小 ≈ 并发 worker 数 × 1~2 - 发送端在 EOF 后需显式
close(ch)，消费端用for chunk := range ch安全退出，避免死锁
os.Open + io.ReadAt 比 bufio.Reader 更适合分片场景
bufio.Reader 是为流式解析设计的，内部有缓冲、有回退、有行边界感知，但分片上传/分割要求的是**确定性字节偏移**。一旦你用 bufio.Scanner 或 ReadString('\n')，二进制文件就废了。
io.ReadAt 是唯一能精确从指定 offset 开始读取指定长度的 API，且不改变文件指针，天然支持并发安全读取。
- 打开文件用
os.Open，不是os.OpenFile(..., os.O_RDONLY)—— 后者多此一举 - 每个分片读取：先
file.Stat()拿总大小，再循环调用io.ReadAt(buf, offset)，返回值n, err必须检查：err == io.EOF表示结束，n == 0 && err == nil是合法的空块（如刚好对齐） - 别自己实现“跳过已上传分片”的逻辑去改
offset，而是把已成功上传的Index存本地 JSON，启动时过滤掉对应 chunk 的发送
并发上传时最容易忽略的三个状态同步点
通道能传数据，但不能自动解决“哪块传完了”“哪块失败了”“合并该不该触发”。这些必须靠外部状态协同，否则断点续传就是假的。
- 服务端返回的
ETag或part_id必须和客户端生成的chunk_id（如sha256(file_path + strconv.Itoa(i))[:8]）严格一致，否则无法去重或校验 - 本地记录文件不能只存成功列表，还得存失败时间戳和重试次数，避免无限重试一个永远超时的分片
- 合并请求（如
POST /merge）必须携带所有已上传分片的Index列表，服务端据此比对/tmp/upload/{id}/下实际存在的文件，缺一不可才允许合并
