Benchmark测试I/O必须防止编译器优化：需让结果参与计算或丢入blackhole变量；应复用文件句柄、预建大临时文件、清缓存，并重点关注B/op和allocs/op而非仅ns/op。
用Benchmark函数测真实I/O耗时
直接写os.ReadFile或os.WriteFile的基准测试容易被编译器优化掉，导致ns/op虚低。必须让读写结果参与计算或显式丢弃到blackhole变量，否则测的不是I/O，是“什么都没干”的开销。
- 在循环内调用
b.N次操作，但每次都要打开/关闭文件会放大系统调用开销，应提前准备文件句柄并复用 - 测试前生成足够大的临时文件（如10MB），避免缓存干扰；小文件可能全驻内存，测不出磁盘I/O真实延迟
- 用
io.Discard或blackhole := 0接收返回值，防止Go 1.22+编译器自动消除无副作用调用
go test -bench=.输出里哪些指标真有用
ns/op只是表象，关键要看B/op和allocs/op——它们暴露内存分配是否失控。比如os.ReadFile返回新[]byte，每次调用都分配堆内存；而用bufio.Reader配固定大小缓冲区，allocs/op可降到接近0。
-
B/op > 4096通常意味着单次操作分配了整块缓冲，需检查是否重复make([]byte, size) -
allocs/op ≥ 2说明至少有一次额外分配，常见于strings.Split、fmt.Sprintf等隐式分配场景 - 对比优化前后数据时，优先看
ns/op下降比例是否匹配B/op下降比例；若耗时降了20%但内存分配没变，说明瓶颈不在内存路径上
替换os.ReadFile为bufio.Reader要注意缓冲区大小
默认bufio.NewReader(f)用4KB缓冲，对小文件够用，但读取大日志文件时，频繁填满缓冲再触发系统调用仍不高效。实测中32KB~128KB缓冲常带来5%~15%吞吐提升，但超过256KB收益递减，且增加首字节延迟。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要在循环里反复调用
bufio.NewReader——它本身要分配缓冲内存；应在基准函数外初始化一次 - 用
reader.Peek(1)或reader.ReadByte()做逐字节处理时，小缓冲反而更快；流式解析大文本才适合大缓冲 - 如果目标是读完即丢，用
io.Copy(io.Discard, reader)比reader.Read()循环更省心，也更贴近生产中“消费而不保留”的场景
并发读写文件时os.File不是线程安全的
多个goroutine共用一个*os.File并调用Read/Write会引发竞态，即使加sync.Mutex也解决不了底层文件偏移量冲突。正确做法是每个goroutine独占一个打开的文件句柄，或改用io.MultiReader合并多个文件流。
- 用
runtime.GOMAXPROCS(1)跑基准测试能排除调度干扰，先确认单协程性能基线 - 并发数设为2/4/8逐步测试，观察
ns/op是否线性下降；若到4 goroutine就饱和，可能是磁盘IOPS或文件系统锁瓶颈 - Linux下注意
/proc/sys/fs/file-max限制，大量并发文件操作可能触发too many open files错误，需提前调高ulimit
实际压测中，最易被忽略的是测试环境与生产环境的I/O栈差异：本地SSD、容器内overlayfs、K8s挂载的NFS，三者随机读延迟能差两个数量级。基准测试代码写得再准，跑在错的存储层上，数据就不可信。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
