io.CopyN 是按固定字节切分大文件最稳妥的方式，避免内存爆炸；需零填充命名分片、顺序合并并用 SHA256 校验完整性。
用 io.CopyN 按固定字节切分大文件，避免内存爆炸
Go 本身不提供“直接 split”命令，但 io.CopyN 是最稳妥的底层工具——它能精确控制每次复制多少字节，不加载整个文件进内存。适合 GB 级日志、数据库 dump 文件等场景。
常见错误是用 os.ReadFile 读全量再切片，1GB 文件会直接 OOM；或者用 bufio.Scanner 按行切，但二进制文件没“行”的概念，会破坏数据。
- 打开源文件用
os.Open，每个分片用os.Create单独写入 - 每次调用
io.CopyN(dst, src, chunkSize)，返回实际复制字节数，需检查是否为0（表示已到 EOF） - 注意最后一个小于
chunkSize的剩余块，io.CopyN会自动处理，无需额外判断长度
合并文件时用 io.Copy 顺序追加，别用字符串拼接
合并的本质是把多个分片按序写入一个新文件，io.Copy 是最高效的方式。有人尝试用 strings.Join 或 bytes.Buffer 把所有分片内容先读进内存再写，这在分片数多或单个分片大时极易触发内存溢出。
- 目标文件用
os.Create创建，不是os.OpenFile(..., os.O_APPEND)——后者在并发写入或未清空时易出错 - 按文件名自然顺序遍历分片（如
part_001,part_002），用filepath.Glob("part_*")+sort.Strings确保顺序 - 每个分片用
os.Open后直接io.Copy(mergedFile, partFile)，完成后Close
分片命名必须带零填充序号，否则合并顺序错乱
Go 的 filepath.Glob 和 shell 的 ls 默认按字典序排序：part_1, part_10, part_2 会被排成 1→10→2，导致合并后数据错位。这不是 Go 特有，而是所有基于字符串排序的通用陷阱。
立即学习“go语言免费学习笔记（深入）”；
- 生成分片名时强制使用零填充，如
fmt.Sprintf("part_%03d", i)→part_001,part_002 - 不要依赖时间戳或随机字符串做排序依据，它们无法保证逻辑顺序
- 若必须用自定义前缀（如
backup_20240501_part_001），提取序号部分再转成整数排序
校验合并完整性：用 crypto/sha256 对比原始与合并后文件哈希
分割合并过程看似简单，但 I/O 错误、权限问题、截断写入都可能导致静默损坏。仅靠文件大小一致不能说明内容正确——比如末尾几个字节丢失，大小可能不变（因文件系统对齐）。
- 分割前计算原始文件哈希：
sha256.Sum256+io.Copy流式计算，不加载全文 - 合并后对新文件做同样哈希计算，对比两个
[32]byte值是否相等 - 不要用
md5，碰撞风险高；也不要用os.Stat().Size替代哈希校验
真正麻烦的不是写不对，而是写对了却没校验——数据损坏往往在几个月后才发现，那时原始文件可能已被清理。
