大文件分块读取应避免内存溢出，需用os.open配合io.readfull或bufio.reader按固定大小（如64kb）流式读取，预分配切片、及时截取有效数据，为每块添加含seq、crc32、islast字段的packet结构以支持有序重组与校验。
大文件分块读取时如何避免内存溢出
直接 os.ReadFile 读整个 GB 级文件进内存，Go 程序会瞬间 OOM。必须用流式读取 + 分块处理。核心是用 os.Open 打开文件后，配合 io.ReadFull 或 bufio.Reader.Read 按固定大小（如 64KB、1MB）反复读，每次只持有当前 chunk 的数据。
注意：不要用 bytes.Buffer 累积所有 chunk，也不要提前调用 file.Stat().Size() 去算总块数——某些网络文件系统或管道不支持 Stat，会 panic。
- 推荐 chunk 大小设为
65536（64KB），兼顾网络 MTU 和 GC 压力 - 用
make([]byte, chunkSize)预分配切片，避免频繁扩容 - 每次
readLen, err := reader.Read(buf)后，立即用buf[:readLen]构造有效数据切片，别直接传整块buf
给每个数据包加唯一序号和校验字段
接收端靠序号重装文件，靠校验字段判断是否损坏。Go 标准库的 hash/crc32 足够快且足够可靠，比 md5 或 sha256 更适合单包校验。
结构体定义建议如下：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
type Packet struct {
Seq uint64
Data []byte
CRC32 uint32
IsLast bool
}
-
Seq从0开始递增，接收端严格按顺序写入临时文件 -
CRC32必须在序列化前计算：crc32.Checksum(data, crc32.IEEETable) -
IsLast不能靠readLen 判断——因为最后一块也可能刚好填满，必须等 <code>err == io.EOF才设为true
发送端如何控制并发与背压
一口气把几千个 Packet 塞进 channel，又没缓冲或限速，下游协程来不及处理就会卡死或丢包。真实场景中要结合传输协议（TCP/UDP/WebSocket）做节流。
- TCP 场景下，用带缓冲 channel（如
make(chan Packet, 16)），配合net.Conn.SetWriteDeadline防卡住 - 如果用
http.Post逐包发 HTTP，务必设置http.Client.Timeout，并重试非 2xx 响应 - 关键点：发送逻辑里不要
select { case ch 就完事，得加超时分支，否则 channel 满了会永久阻塞
接收端如何安全拼接并校验完整文件
收到的包可能乱序、重复、丢失。简单方案是要求发送端严格顺序发送 + TCP 保序，接收端只做线性写入；复杂场景需引入滑动窗口或消息 ID 去重。
最易忽略的是文件写入的原子性：不要边收边往目标路径写，而是先写到 filename.part，全部收完再 os.Rename 替换。
- 每写一块前，校验
CRC32，失败则丢弃该包并记录日志（"packet seq=123 crc mismatch"） - 用
os.O_CREATE | os.O_WRONLY | os.O_APPEND打开临时文件，避免 seek 错误 -
IsLast == true包收到后，立刻关闭文件句柄，并对整个.part文件再跑一次sha256.Sum256全局校验（可选，用于最终一致性）
分块边界对齐、CRC 计算时机、临时文件命名冲突、channel 缓冲大小——这些地方不细看文档很容易出 silent bug。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
