Go文件写入不保证落盘，必须显式调用file.Sync()强制刷盘至物理介质；os.WriteFile仅原子覆盖内容，数据停留页缓存；bufio.Writer需先Flush()再Sync()才能确保持久化。
Go 程序读文件时，os.ReadFile 返回的数据不一定是“刚从磁盘读的”，它可能来自内核页缓存（page cache）；写文件时，file.Write 成功也不代表数据已落盘——它大概率只进了内核缓冲区。这不是 Go 的 bug，而是 Linux 文件系统与用户态程序协作的基本事实。
为什么 os.Open 后读取速度忽快忽慢？
因为内核 page cache 是否命中决定实际 I/O 走不走磁盘。首次读大文件会触发真实磁盘读 + 填充 cache；后续相同偏移再读，直接从内存返回。但这个 cache 不受 Go 控制，也不保证长期驻留——内存压力大时会被回收，或被其他进程驱逐。
- 用
echo 3 > /proc/sys/vm/drop_caches可手动清空（仅测试用），验证是否真依赖 cache -
os.Open本身不触发预读，read(2)系统调用才触发；小 read 请求（如每次 1KB）会让内核难以判断意图，预读失效 - 顺序读场景下，用
bufio.NewReaderSize(f, 64*1024)比裸f.Read更容易让内核预读生效——批量请求更易被识别为流式访问
bufio.Writer 写完不 Flush() 就退出，文件为什么是空的？
因为 bufio.Writer 把数据先写进自己的内存缓冲区（默认 4KB），不是直接交到内核。程序退出时，Go 运行时不会自动帮你刷 buffer——它只关文件描述符，而内核此时还没收到那批数据。
-
file.Sync()是另一层：它要求内核把已接收的数据真正刷到磁盘物理介质，比Flush()更重 - 常见错误写法：
defer w.Flush()放在os.Create后但没包在函数作用域里，panic 时根本没执行 - 安全习惯：写完立刻
w.Flush()；若后续还要写，用defer w.Flush()在函数末尾；确定写死就用os.WriteFile一步到位
大文件随机读用 bufio.Reader 反而更慢？
是的。随机读（比如按 offset 查日志某条记录、解析数据库索引块）时，bufio.Reader 的内部偏移管理、缓冲区填充逻辑全是干扰项——你只要 512 字节，它却预读了 4KB 到缓冲区，还维护了额外状态。
立即学习“go语言免费学习笔记（深入）”；
- 直接用
f.ReadAt(buf, offset)，绕过所有 bufio 层，性能更可预测 -
ReadAt是线程安全的，多个 goroutine 并发读不同 offset 无需加锁 - 别用
bufio.NewReader(f).Read混合Seek：seek 会更新*os.File的偏移，但bufio.Reader自己还有个缓冲区偏移，两者不同步 → 跳字节或重复读
高频小文件读写，io.CopyBuffer 的 buf 参数为什么必须是切片？
因为 io.CopyBuffer(dst, src, buf) 的第三个参数类型是 []byte，传数组字面量（如 [4096]byte{}）会导致每次调用都分配新内存，失去复用意义，GC 压力陡增。
- 正确做法：用
sync.Pool管理固定大小切片，buf := bufPool.Get().([]byte); io.CopyBuffer(dst, src, buf[:0]); bufPool.Put(buf) - 缓冲区大小不是越大越好：128KB 对 NVMe 是甜点，但设成 2MB 容易引发 L3 cache miss，且单次系统调用阻塞时间变长，影响 goroutine 调度
- 注意目标
dst接口能力：如果 dst 是 TLS 连接或某些自定义io.Writer，过大的 buf 可能被拆成多次Write调用，反而增加开销
最常被忽略的一点：缓存行为永远是分层的——Go 的 bufio 缓冲、内核 page cache、SSD 主控 DRAM 缓存、甚至 CPU L3 cache 都在起作用。调优时不能只盯着某一层，得用 strace -e trace=read,write,fsync 和 perf record -e block:block_rq_issue 实测 syscall 和块设备行为，否则容易在错误的方向上加大缓冲。
