最稳合并二进制碎片的方法是用os.create创建目标文件，按序遍历排序后的碎片，逐个io.copy流式写入；避免seek、手动拼接、os.openfile误配标志；需校验sha256.sum256而非仅比大小。
用 os.Create 和 io.Copy 合并碎片文件最稳
Go 里合并二进制碎片，别碰 os.OpenFile 配 Seek 写入——容易错位、覆盖、漏字节。直接按顺序打开每个碎片，用 io.Copy 流式写入目标文件，内存占用低、逻辑清晰、不易出错。
常见错误是手动读 []byte 再拼接：大文件下内存暴涨，还可能因 buffer 大小不一致导致末尾截断。
- 确保碎片文件名有序（如
asset_001.bin、asset_002.bin），用filepath.Glob或sort.Strings排好再遍历 - 目标文件用
os.Create，不是os.OpenFile(..., os.O_CREATE|os.O_WRONLY)—— 前者自动清空，后者若误加os.O_APPEND会追加而非重写 - 每拷贝完一个碎片，调用
dstFile.Sync()（可选）；若中途崩溃需强一致性，才加；否则纯吞吐场景可省，性能提升明显
io.MultiReader 能避免临时合并，但只适合“只读”场景
如果只是要读取拼接后的完整资产（比如解密、校验、上传），根本不用落地成单个大文件。用 io.MultiReader 把多个 *os.File 或 io.Reader 串起来，对外表现就是一个连续流。
优势是零磁盘 IO、无临时空间占用；劣势是无法随机 seek（MultiReader 不实现 io.Seeker），也不能重复读（除非封装成 bytes.Reader 或缓存到内存）。
立即学习“go语言免费学习笔记（深入）”；
- 碎片必须全部保持打开状态，注意文件描述符上限；Linux 默认 1024，上万碎片会报
too many open files - 若需部分读取（如只读前 1MB 头部），优先用
io.LimitReader包一层，避免全量加载 - 和
http.Request.Body等非重放流组合时，先io.ReadAll到[]byte再传给MultiReader，否则原始流可能已被消费
分割大文件时，bufio.NewReader 比裸 Read 更可控
用 os.Open 读大文件再分块写入碎片，别直接 Read([]byte) 循环——buffer 大小没对齐时，最后一块可能比预期小，且难以判断 EOF 是否干净结束。
加一层 bufio.NewReader，配合 ReadFull + io.ErrUnexpectedEOF 判断，能明确区分“读到末尾”和“读失败”。
- 设固定块大小（如 5MB），用
make([]byte, chunkSize)分配 buffer，避免频繁 GC - 每次
ReadFull成功后立即写入新碎片；若返回io.ErrUnexpectedEOF，说明是最后一块，用实际读取长度写入（不要补零） - Windows 下注意文件名长度限制，碎片序号建议用 6 位数字（
%06d），避免路径超长导致CreateFile失败
校验合并结果：别只比 os.Stat().Size，得算 sha256.Sum256
文件大小一致 ≠ 内容一致。网络传输、磁盘静默错误、写入中断都可能导致某块碎片末尾损坏，但总大小没变。
真要可靠，必须在分割前对源文件算一次 sha256.Sum256，合并后再对目标文件重算一次。别用 md5——碰撞风险高，Go 标准库也早标记为 legacy。
- 大文件校验别一次性
io.ReadAll，用hash.Hash配io.Copy流式计算，内存恒定在几 KB - 碎片级校验可选：给每个碎片额外生成
.sha256文件，便于定位哪一块坏了，但会增加 I/O 和存储开销 - 注意：
sha256.Sum256是值类型，打印时用fmt.Printf("%x", sum)，别直接fmt.Println(sum)——输出的是结构体字段，不是哈希值
