Go文件I/O基准测试必须用func BenchmarkXxx(b *testing.B)函数并加-bench参数运行；需明确测延迟或吞吐，合理选用os.O_SYNC/O_DSYNC、缓冲区大小及f.Sync()时机，并清理系统缓存确保结果可靠。
Go 文件系统操作的基准测评不是跑 go test 就完事，漏掉 -bench 参数、写错函数签名、或把初始化塞进循环里，测出来的数字基本没参考价值。
为什么 go test -bench=. 没输出？
最常见原因是函数签名或文件名不合规，框架直接跳过——不是报错，是静默忽略。
-
BenchmarkWriteSmallFile函数必须定义在xxx_test.go文件中，且与被测代码同包 - 参数类型必须是
*testing.B，写成*testing.T或漏掉星号，go test -bench=.会显示no benchmarks to run - 函数体里没用
b.N控制循环（比如硬编码for i := 0; i ），框架无法动态调整采样次数，结果不具可比性 - 忘记加
-bench参数：只运行go test或go test -v，Benchmark 函数压根不会执行
如何正确测量真实写入延迟？
默认 os.WriteFile 或 os.OpenFile(..., os.O_WRONLY|os.O_CREATE, 0644) 是异步写入，返回时数据可能还在页缓存里，不代表已落盘。要测“持久化性能”，得强制刷盘。
- 加
os.O_SYNC：保证write返回前，数据 + 元数据（如 mtime）都写入磁盘；机械盘上小块写可能从 0.1ms 跳到 10ms+ - 加
os.O_DSYNC：只同步数据，不等元数据，略快一点，但 SSD/NVMe 上差距仍明显 - 手动调
f.Sync()：适用于已打开的文件句柄，注意它本身也有开销，别在每次b.N迭代里重复调用，应和写操作配对 - 测试前用
sync命令清空 Linux 页缓存，否则首次运行快、后续变慢，结果不可复现
缓冲区大小对 bufio 性能影响有多大？
默认 4KB 缓冲在顺序读写大文件时明显拖慢吞吐，但盲目加大也不行。
立即学习“go语言免费学习笔记（深入）”；
- 读场景：
bufio.NewReaderSize(f, 65536)比默认快 30%–50%，尤其在机械盘上；超过 1MB 后收益趋平，还可能因内存分配抖动拉高 p99 延迟 - 写场景：用
bufio.NewWriterSize(f, 65536)，但必须在每次b.N迭代末尾显式调w.Flush()，否则缓冲未生效 - 避免在循环内反复
make([]byte, size)，提前分配好复用；io.CopyN或io.ReadFull比裸Read更少 syscall 次数 -
bufio.Scanner默认 64KB 缓冲，但按行切分有额外开销，纯吞吐测试别用它
临时文件和资源清理怎么不踩坑？
看似无害的 os.CreateTemp，若不显式清理，多次运行后磁盘碎片增加，性能逐渐劣化。
- 用
os.CreateTemp("", "bench-*.txt")创建临时文件后，必须加defer os.Remove(filename) - 文件创建、
os.OpenFile等初始化操作，一律放在b.ResetTimer()之前，否则初始化开销计入耗时 - 别在
b.N循环里重复打开/关闭文件，应复用句柄；若需多文件并发，注意系统级文件描述符限制 -
b.ReportAllocs()必须在循环前调用，否则-benchmem输出的allocs/op恒为 0
真正难的不是写个 Benchmark 函数，而是让每次运行都处于相同 I/O 状态：缓存干净、文件碎片可控、缓冲策略匹配实际负载。这些细节不控住，数值波动大到没法判断优化是否有效。
