go文件i/o性能瓶颈主因是默认行为干扰内核页缓存：os.readfile三连操作、频繁open/close导致inode缓存失效，小缓冲（4kb）使预读失效；推荐bufio.newreadersize设64kb～128kb（ssd）或32kb（hdd/nfs）以匹配内核预读窗口。
Go 程序的文件系统性能瓶颈，往往不是 CPU 或磁盘本身，而是你没意识到 os 和 io 包默认行为如何绕过、干扰甚至浪费内核页缓存（page cache）。
为什么 os.Open + Read 会绕过内核页缓存？
Linux 内核页缓存对普通 open() + read() 是透明生效的——但 Go 的 os.Open 默认带 O_CLOEXEC，而某些场景下（如容器中挂载的 NFS、FUSE 文件系统、或被 seccomp 限制的环境），O_DIRECT 可能被隐式启用，导致绕过页缓存；更常见的是：频繁 os.Open/os.Close 让内核无法有效保有文件 inode 和 page cache 映射。
- 每次
os.Open都触发完整 VFS 路径解析和权限检查，inode 缓存可能被踢出 -
os.ReadFile内部是open → read → close三连，对同一文件反复调用等于主动拒绝复用页缓存 - 小缓冲读（如默认
bufio.NewReader的 4KB）导致大量短read()系统调用，页缓存预读失效
bufio.Reader 缓冲大小怎么设才不浪费页缓存？
缓冲区不是越大越好，关键要匹配内核页缓存行为。Linux 默认页大小 4KB，预读窗口通常是 128KB～512KB（取决于存储类型和访问模式），bufio.Reader 缓冲应与之对齐，而非拍脑袋设 1MB。
- SSD/NVMe 上顺序读大文件（>10MB）：
bufio.NewReaderSize(file, 64*1024)或128*1024—— 减少系统调用次数，又不超出预读窗口，实测比默认 4KB 快 3× 以上 - HDD 或远程存储（NFS/CIFS）：
32*1024更稳，避免单次 read 过大引发延迟毛刺 - 随机读小文件（file.Read()，跳过
bufio一层间接，反而减少内存拷贝和指针跳转开销
并发读文件时，ReadAt 比 Seek+Read 更安全？
是的，但前提是你复用了 *os.File。多个 goroutine 对同一个 *os.File 调用 Seek + Read 会竞争内部 file.offset 字段，导致读错位置或 panic；ReadAt 是纯函数式，偏移量由调用方传入，无状态共享。
- 必须确保每个
ReadAt的offset不重叠，否则内容会覆盖写入目标 buffer -
ReadAt不改变file.offset，所以不影响其他 goroutine 后续的Read行为（如果它们还混用） - 注意：Windows 下
ReadAt性能略低于 Linux，因底层实现差异，高并发时建议压测验证
os.Stat 和 os.IsNotExist 判定存在性太重？
是。os.Stat 获取完整元数据（atime/mtime/size/inode/link target），而多数“是否存在”逻辑只需要知道路径能不能打开。尤其在 NFS 或 rootless 容器里，os.Stat 可能卡住几百毫秒。
- 仅判断存在且可读：
_, err := os.OpenFile(path, os.O_RDONLY|os.O_CLOEXEC, 0)，然后检查err == nil || errors.Is(err, fs.ErrNotExist) - 批量判断多个路径：用
filepath.WalkDir一次遍历，避免 N 次 stat -
os.IsNotExist(err)只识别syscall.ENOENT，某些挂载点返回syscall.EACCES，需额外判errors.Is(err, fs.ErrPermission)
真正难处理的不是“怎么缓存”，而是“什么时候不该缓存”——比如日志追加写必须绕过页缓存直写磁盘，否则 crash 后丢失最后一段；又比如 mmap 大文件做随机访问时，页缓存反而成负担。这些边界条件，比选个缓冲大小重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
