应使用 bytes.Buffer 替代 os.File 进行基准测试，因其零系统调用、无 IO 干扰；需在每次迭代前重置缓冲区以避免数据累积导致吞吐量虚高。
基准测试里文件读写拖慢结果？用 bytes.Buffer 替代 os.File
Go 的 Benchmark 函数默认跑在真实环境里，一旦代码调用 os.Open 或 io.Copy 到磁盘文件，IO 延迟、缓存状态、磁盘负载都会污染测量结果。这不是你算法慢，是硬盘在抢戏。
正确做法是把 IO 路径“拔掉”，换成内存中的等价体：bytes.Buffer（写）或 bytes.NewReader（读）。它们实现 io.Reader/io.Writer 接口，零系统调用，无副作用，且行为一致。
- 别用
tempfile := os.TempDir() + "/test.dat"再os.Create—— 这仍是真实 IO - 别在
Benchmark里反复os.Remove清理 —— 删除本身也耗时，且可能失败 - 如果原逻辑依赖
*os.File特有方法（如Stat()、Sync()），说明你测的不是纯计算逻辑，得拆出可测子函数
io.Copy 测速时为什么不能直接换 bytes.Buffer？
表面看 io.Copy(dst, src) 换成 io.Copy(&buffer, reader) 就行，但容易漏掉一个关键点：目标 dst 的初始状态。比如你原本写文件，系统会自动 truncate；而 bytes.Buffer 默认追加，多次 benchmark 迭代后数据越积越多，吞吐量虚高。
解决方式很简单：每次迭代前重置缓冲区。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func BenchmarkCopyToBuffer(b *testing.B) {
data := make([]byte, 1024*1024)
reader := bytes.NewReader(data)
var buf bytes.Buffer
b.ResetTimer()
for i := 0; i < b.N; i++ {
buf.Reset() // ← 必须加这句
io.Copy(&buf, reader)
reader.Seek(0, 0) // ← 如果 reader 不是可重用的，也要重置
}
}
需要模拟真实文件元信息？别碰 os.Stat，用结构体字段代替
有些逻辑会根据文件大小、修改时间做分支（比如跳过空文件、按 mtime 排序）。在基准测试里调 os.Stat 不仅引入 IO，还让结果随文件系统缓存波动。
真正该测的是“根据 size 做判断”这段逻辑，而不是 stat 本身。把元信息抽象成普通 struct 字段传入：
- 原函数：
func ProcessFile(path string) error { info, _ := os.Stat(path); if info.Size() == 0 { ... } } - 重构后：
func ProcessFileInfo(size int64, modTime time.Time) error { if size == 0 { ... } } - 基准测试里直接传
1024或0，完全绕过系统调用
为什么不用 ioutil.NopCloser 或 strings.Reader？
strings.Reader 只支持 string 输入，无法高效复用大块二进制数据（会触发额外的 string → []byte 转换）；ioutil.NopCloser（已弃用）只是包一层 Close()，不解决底层 IO 问题。
优先级如下：
- 读场景：用
bytes.NewReader(data)—— 支持任意[]byte，无拷贝，可Seek() - 写场景：用
bytes.Buffer—— 自动扩容，提供Bytes()和Reset() - 流式处理（如管道）：组合
io.Pipe()，但仅当必须测 goroutine 协作时才用，多数情况过度设计
内存缓冲不是“假装快”，而是把变量声明、切片分配、内存拷贝这些可控成本单独拎出来——这才是你该优化的地方。硬盘和 SSD 的差异，在 bytes.Buffer 面前根本不存在。
