os.ReadFile会一次性将整个文件加载到内存，导致大文件场景下内存耗尽或GC压力剧增；应改用os.Open+bufio.NewReader分块读取，或bufio.Scanner处理流式格式，必要时结合io.Seeker实现随机访问。
为什么 os.ReadFile 在大文件场景下会吃光内存
os.ReadFile 会一次性把整个文件读入内存，对几百 MB 甚至 GB 级文件，直接触发 GC 压力或 OOM。它本质是 io.ReadAll(io.Reader) 的封装，没有流式控制能力。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Open+bufio.NewReader分块读取，例如每次reader.Read(buf)处理 64KB - 对日志、CSV、JSON Lines 等流式格式，优先用
scanner := bufio.NewScanner(file)，避免手动管理缓冲区 - 若需随机访问（如解析 tar、zip 内部文件），改用
io.Seeker配合io.ReadAt，跳过无关区域
使用 bufio.Writer 却没提速？检查是否忘了 Flush()
常见现象：写入大量小字符串时，加了 bufio.Writer 但耗时几乎不变，甚至更慢——大概率是没调用 Flush()，导致数据滞留在缓冲区，最终在 GC 或 defer 清理时集中刷盘，掩盖了优化效果。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在循环写入后、关闭前必须显式调用
w.Flush()；若不确定时机，可在 defer 中加defer w.Flush() - 缓冲区大小不是越大越好：
bufio.NewWriterSize(w, 1（1MB）适合顺序写大文件，但对高频小写（如每行一条日志），64KB~256KB 更平衡缓存命中与延迟 - 避免在 goroutine 中复用同一
*bufio.Writer，它不是并发安全的；高并发写建议每个 goroutine 独立实例
ioutil.WriteFile 已被弃用，但 os.WriteFile 仍有陷阱
os.WriteFile 虽替代了旧 API，但它仍是全量写入：先构建完整字节切片，再一次性写入。若内容来自模板渲染、JSON 序列化等中间过程，会额外产生一次内存拷贝。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对动态生成内容，绕过
os.WriteFile，直接写到*os.File或bufio.Writer，例如：json.NewEncoder(w).Encode(v) - 注意权限参数：
os.WriteFile("x.log", data, 0600)中的0600是八进制字面量，写成600（十进制）会导致权限错误（实际为 0o1130） - 若需原子写（防中断损坏），不要依赖
os.WriteFile的“覆盖”语义；应写入临时文件后os.Rename，并确保目标目录支持原子 rename（Linux OK，NFS 可能失败）
同步 I/O vs 异步 I/O：Golang 里其实没真正的异步文件 I/O
Go 运行时在 Linux 上用 epoll 管理网络 I/O，但文件 I/O 始终是阻塞系统调用（read/write）。所谓“异步”，只能靠 goroutine 模拟：每个文件操作起一个 goroutine，由 OS 线程池调度。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要为单个大文件读写盲目开 goroutine——OS 线程切换开销可能超过收益；优先优化单线程吞吐（缓冲区、零拷贝、mmap）
- 对多文件并发处理（如批量压缩），用
sync.WaitGroup+ goroutine 是合理选择，但需限制并发数（如sem := make(chan struct{}, 8)）防句柄耗尽 - 极端场景可考虑
mmap（通过golang.org/x/exp/mmap或 syscall），跳过内核缓冲区拷贝，但需手动处理 page fault 和 sync，调试成本高
真正卡住性能的，往往不是函数选错，而是缓冲区大小和 flush 时机这种细节——它们不会报错，只悄悄拖慢十倍。
