os.ReadFile读大文件必然OOM，因其内部调用io.ReadAll一次性分配整块内存；超100MB就应改用os.Open+固定缓冲区分块流式处理，避免进程被系统OOM killer终止。
为什么不能直接用 os.ReadFile 读大文件
内存爆掉是常态。比如读一个 2GB 的日志文件，os.ReadFile 会一次性分配 2GB 内存，进程很可能被系统 OOM killer 干掉。更糟的是，如果多个 goroutine 并发调用，问题会指数级放大。分块读取不是为了“炫技”，而是避免把 Go 程序跑成内存泄漏现场。
实际场景中，常见于：上传大文件校验、日志按块解析、视频/镜像文件切片上传、备份工具流式处理——这些都不是“读完再处理”，而是“边读边处理”。
- 分块大小建议设为
64 * 1024（64KB）到1024 * 1024（1MB），太小导致 syscall 过多，太大失去流式意义 - 别用
bufio.Scanner处理未知长度的二进制块，它默认按行切割，遇到 \x00 或超长无换行数据会 panic - 务必检查
io.Read返回的n值，n == 0不一定代表 EOF，可能是空文件或临时阻塞
用 io.ReadFull 和 io.ReadAtLeast 控制分块行为
直接循环调 io.Read 容易出错：最后一块往往不足预定大小，但代码没判断就当完整块处理，导致数据错位或 panic。Go 标准库提供了两个更稳的替代：
-
io.ReadFull：要求**必须读满**指定字节数，否则返回io.ErrUnexpectedEOF—— 适合固定大小块（如加密分片、网络协议头） -
io.ReadAtLeast：保证至少读到 N 字节，允许多读（返回值n可能 > N），适合“最小处理单元”场景（如解析带 magic header 的文件） - 普通分块推荐用
io.Read+ 显式判断：if n
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
buf := make([]byte, 1024*1024)
for {
n, err := file.Read(buf)
if n > 0 {
// 处理 buf[:n]，不是整个 buf
processChunk(buf[:n])
}
if err == io.EOF {
break
}
if err != nil {
return err // 不忽略非 EOF 错误
}
}合并文件时如何避免“追加变覆盖”和权限丢失
用 os.OpenFile 以 os.O_CREATE | os.O_WRONLY | os.O_APPEND 模式打开目标文件，看似安全，但有个隐藏坑：如果目标文件不存在，O_APPEND 会创建它，但默认权限是 0666 &^ umask（通常是 0644），而源文件可能是 0600 或 0755。合并后执行权限没了，脚本文件直接变废。
- 先用
os.Stat检查目标文件是否存在，存在则复用其Mode()，不存在则用首个源文件的 mode 初始化 - 不要用
io.Copy直接合并：它不处理偏移，且无法控制 buffer 大小，大文件下可能吃光内存 - 手动控制 write offset：对每个源文件，用
dst.WriteAt(chunk, offset)，然后offset += int64(len(chunk)) - 合并中途失败时，残留的半成品文件要主动
os.Remove，否则下次运行会误续写
并发分块读取要注意 *os.File 的 seek 竞态
同一个 *os.File 被多个 goroutine 同时 Read 或 Seek，文件偏移量会乱。这不是 Go bug，是底层 OS 文件描述符共享导致的竞态。即使你给每个 goroutine 分配独立 buffer，只要共用 file handle，结果就不可预测。
- 方案一：用
file.Seek+io.ReadFull手动定位每个块起始位置，每个 goroutine 自己 seek 再 read（注意 seek 返回值检查） - 方案二：提前把文件分段信息（start, end）算好，传给每个 goroutine，它们各自
os.Open同一文件再file.Seek(start, 0)（Linux 支持多 fd 指向同一 inode） - 绝对不要：启动 goroutine 后直接在循环里
file.Read—— 没锁也没隔离，结果随缘
真正需要并发读的场景（如分布式校验），优先考虑 mmap 或预分片到多个小文件，而不是硬刚单文件并发 seek。
