Linux下Go文件I/O缓存优化的核心是内核缓存与用户态缓冲协同工作；推荐顺序读用64KB bufio缓冲，SSD场景用128KB切片，禁用mmap小文件，实测调优优于理论配置。
linux 下 go 文件 i/o 的缓存优化，核心不是“绕过内核缓存”，而是**让内核缓存和用户态缓冲协同工作，而不是互相干扰或重复做功**。盲目调大缓冲、滥用 mmap、忽略预读机制，反而会让性能更差。
bufio.NewReaderSize 该设多大？别信默认 4KB
默认 bufio.NewReader 用 4KB 缓冲，在 NVMe 或高吞吐日志场景下明显偏小：频繁填缓冲 → 频繁系统调用 → syscall 占比飙升。但设成 2MB 又容易引发 L3 cache miss 和 goroutine 阻塞。
- 顺序读（日志、CSV、JSON 流）：推荐
bufio.NewReaderSize(f, 64*1024)—— 64KB 在千兆网/PCIe SSD 上吞吐与延迟较平衡 - 机械盘或高并发小文件：32KB 更稳，避免单次 read 阻塞太久
- 定长二进制记录（如 protobuf 帧头）：直接跳过
bufio，用f.Read(buf)复用切片，避免ReadString或ReadBytes的长度不确定性 - 别对同一
*os.File套多个bufio.Reader—— 底层文件偏移不同步，会跳字节或重复读
io.CopyBuffer 比 io.Copy 更可控，但 buf 必须是切片
io.Copy 内部用 32KB 临时缓冲，每次调用都 new 一次，高频小文件拷贝（如微服务间中转）会显著抬高 GC 压力。而 io.CopyBuffer 允许你传入复用的缓冲，但参数类型极易踩坑。
- 正确用法：
buf := bufPool.Get().([]byte); io.CopyBuffer(dst, src, buf[:0]); bufPool.Put(buf) - 错误写法：
io.CopyBuffer(dst, src, [4096]byte{})—— 数组字面量每次触发新分配，失去复用意义 - 缓冲大小建议：SSD 场景可用
make([]byte, 0, 128*1024)；网络转发（如 HTTP body 落盘）用 64–128KB 更合适 - 注意：若
dst是 TLS 连接等不支持部分写的接口，过大缓冲可能反致多次Write，需实测
别依赖内核预读，尤其在机械盘或随机 seek 场景
os.Open 返回的 *os.File 不带预读逻辑，Linux 内核也不会主动为你多读后续块。靠 readahead 系统调用（Go 标准库未封装）风险高：需 cgo、跨平台难、且在高并发下易被内核调度器压制。
- 大文件顺序读：显式用
f.ReadAt(buf, offset)+sync.Pool管理固定大小缓冲（如 128KB），自己控制读节奏 - 追加写日志：务必用
os.O_APPEND打开，内核保证原子性，比手动Seek(0, io.SeekEnd)更快更稳 - 随机读写（如索引查找）：优先用
f.ReadAt(buf, offset)，绕过bufio的偏移管理开销，比 mmap 更可控 - 别在循环里反复
defer f.Close()—— 小文件批量处理时，close本身也有 syscall 开销累积
mmap 不是银弹，只适合 GB 级只读随机访问
mmap 把文件页交给虚拟内存管理，适合只读、访问不连续、GB 级以上的大文件（如数据库快照、词向量索引）。但它不解决写入延迟，也不减少系统调用次数——只是换了一种数据搬运方式。
- Go 标准库无
mmap封装，得用golang.org/x/sys/unix调用底层 API，映射后必须配对Munmap，否则虚拟内存泄漏 - 写入场景慎用：mmap 后的写操作仍需
msync或fsync落盘，吞吐未必比WriteAt+ 定期Sync高 - 小文件或流式读取（如日志 tail）：
mmap反而增加 page fault 开销，不如bufio简单有效 - 真正卡点常在缓冲区大小、并发粒度、是否复用切片，而不是 mmap 本身
最常被忽略的是：缓冲区大小和并发数没有“通用最优解”，它取决于你的磁盘类型、I/O 模式、GC 敏感度和延迟容忍。实测永远比理论配置重要 —— 用 go tool pprof -http=:8080 看 syscall 占比，用 iostat -x 1 观察 %util 和 await，才能确认优化是否真起效。
