最稳合并二进制碎片的方法是用os.Create创建目标文件，按序遍历排序后的碎片，逐个io.Copy流式写入；避免Seek、手动拼接、os.OpenFile误配标志；需校验sha256.Sum256而非仅比大小。
直接用 os.Create + io.Copy 拼接碎片最稳，别碰 os.OpenFile 配 Seek；解包时若只是读取校验或上传，优先用 io.MultiReader 避免落地大文件。
拼接碎片：为什么不用 Seek 写入
用 os.OpenFile 打开目标文件并调用 Seek 定位再写，看似可控，实则极易出错：
- 碎片顺序错一位，
Seek位置就偏移，后续所有字节错位 - 某碎片末尾因 EOF 判断不严少写几个字节，后面所有碎片全错位
-
os.O_APPEND误加进标志位，导致内容追加而非覆盖，旧碎片残留
而 os.Create 创建新文件天然清空，配合按序打开每个碎片、逐个 io.Copy 流式写入，内存占用低、无状态依赖、失败后重试也只需从当前碎片开始。
解包读取：MultiReader 何时能替代落地文件
如果你的下游操作不要求随机访问（比如只做 SHA256 校验、AES 解密、HTTP 上传），io.MultiReader 是更优选择：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 零磁盘 IO，不生成临时大文件，节省空间和 I/O 延迟
- 多个
*os.File按序传入，对外暴露一个连续io.Reader - 注意：它不实现
io.Seeker，无法Seek(0, io.SeekStart)重读；也不能重复读，除非你手动io.ReadAll到[]byte再封装 - 上万碎片会触发
too many open files，Linux 默认 fd 限制 1024，需提前ulimit -n或分批处理
binary.Read 解包结构体：三个硬性条件缺一不可
想用 binary.Read 直接解析拼接后的二进制流（或 MultiReader 封装的流）中的 header，必须同时满足：
- 结构体字段全部首字母大写（导出），小写字段会被静默跳过
- 字段类型严格定长：
int32、uint16、[32]byte可用；int、string、[]byte会 panic 或读错 - 字节序与协议一致：抓包看原始 hex，
00 00 01 00→uint32 = 256→ 用binary.BigEndian；00 01 00 00→ 小端 → 用binary.LittleEndian
常见错误是把整个流丢给 binary.Read 而不先分包——TCP 或文件头未分离时，header 字段必然错位。务必先提取长度字段，再用 io.ReadFull 拿完整包体，最后交给 binary.Read。
分割大文件：bufio.NewReader 比裸 Read 更可靠
用 os.Open 读大文件再切块写入碎片时，别直接 Read([]byte) 循环：
- 最后一次
Read可能返回n < len(buf)，但未必是 EOF（比如刚好读满 buffer），靠err == io.EOF判断不稳 - 裸
Read不保证读满，容易漏字节或截断最后一块 -
bufio.NewReader提供ReadFull和ReadSlice，可精确控制每块大小；配合预分配make([]byte, chunkSize)复用缓冲区，避免高频 GC
真正关键的不是“怎么快”，而是“怎么不丢字节”——bufio.NewReader 的边界控制能力，比手写循环更贴近协议级可靠性要求。
