go语言分割文件应采用流式读取+io.copyn精确截断，避免os.readfile全量加载致oom或bufio.scanner破坏二进制数据；用os.open和os.create配合io.copyn按字节切分，eof时自动返回实际字节数。
Go 语言按固定长度分割文件内容，核心不是“切片”而是“流式读取 + 精确截断”，否则容易产生零填充、数据错位或内存溢出。
用 io.CopyN 按字节精确切分，避免 os.ReadFile 全量加载
常见错误是直接用 os.ReadFile 把整个文件读进内存再用 []byte 切片——1GB 文件会 OOM；bufio.Scanner 又只适合文本，对二进制文件会破坏数据。
-
io.CopyN(dst, src, n)是最稳妥的底层方式：每次只复制指定字节数，不缓存全量，也不依赖换行符 - 源文件用
os.Open打开，每个分片用os.Create单独写入，避免并发或追加写入导致的截断 -
io.CopyN在 EOF 时自动返回实际复制字节数（可能 - 不要用
make([]byte, chunkSize)预分配大缓冲区后反复Read再切片——末尾块会残留未读数据或零值填充
分片命名必须零填充，否则 filepath.Glob("part_*") 排序错乱
合并时若按字符串顺序遍历分片，part_1、part_10、part_2 会被排成 1→10→2，导致数据拼接错位——这不是 Go 特有，是所有字典序排序的通病。
- 生成名必须用
fmt.Sprintf("part_%03d", i)，确保part_001、part_002…part_127 - 合并前用
filepath.Glob("part_*")获取文件列表后，需调用sort.Strings，但仅靠它不够——得提取数字部分转int后排序，否则仍按字符串比 - 别用时间戳或随机字符串做排序依据，它们无法反映逻辑顺序
末尾块要重切片（re-slice），防止 []byte 底层容量污染后续处理
即使你用固定缓冲区 buf := make([]byte, 1024*1024) 读取，最后一块实际只读了 1234 字节，但 buf 的底层数组仍是 1MB，buf[:1234] 才是真实数据。若误传 buf 整体，哈希校验、网络传输都会出错。
- 每次
Read后立即用buf[:n]得到精确数据切片，n是Read返回的实际字节数 - 写入分片时直接用
newfile.Write(buf[:n])，别用newfile.Write(buf) - 如果要做 SHA256 校验，必须基于
buf[:n]计算，否则末尾零值会改变哈希值
合并后必须用 crypto/sha256 校验，不能只比文件大小
文件系统对齐、I/O 截断、权限失败都可能导致静默损坏——比如最后 3 字节没写成功，文件大小却不变。等几个月后才发现，原始文件可能早被清理了。
- 分割前先算一次原始文件的
sha256.Sum256，保存结果 - 合并完成后，对新文件重新计算哈希，逐字节比对两个
[32]byte - 别用
md5，碰撞风险高；也别跳过校验，认为“代码写对了就没事”——生产环境里，没校验=没做完
真正难的不是写出能跑的代码，而是让每一块数据在切、传、合、验四个环节里都不掉字节——尤其是重叠、零填充、排序、哈希这些细节，漏一个，整条链路就不可信。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
