os.WriteFile 在小文件场景下更慢，因其默认先调用 os.Stat 检查路径存在性再决定是否截断，而 os.Create 直接覆盖，省去 stat 开销；Windows 下该开销高 2–3 倍。
为什么 os.WriteFile 在小文件场景下比 os.Create + io.WriteString 慢？
因为 os.WriteFile 默认会先调用 os.Stat 检查目标路径是否存在，再决定是否 truncate；而直接 os.Create 会强制覆盖，跳过 stat 开销。尤其在反复压测（如每轮写 1KB 文件 10000 次）时，这个额外的系统调用会显著拉低吞吐量。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 基准测试中若明确需要覆盖写入，优先用
os.Create+Write组合，避免隐式 stat - 若用
os.WriteFile，可提前确保父目录已存在，并用os.WriteFile(path, data, 0644)显式指定权限，减少内部 fallback 分支 - 注意：Windows 下
os.Stat开销比 Linux 高约 2–3 倍，该差异在跨平台压测中必须单独验证
如何用 testing.B 正确测量同步写入延迟？
直接在 BenchmarkXXX 函数里反复调用 os.WriteFile 会导致每次创建新文件、触发磁盘分配，测出的是「首次写入+元数据开销」，而非纯 IO 延迟。真实服务常复用文件句柄，应模拟该模式。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
b.ResetTimer()前完成文件打开（f, _ := os.OpenFile(...)），并在defer f.Close()放在函数末尾而非循环内 - 每次循环用
f.Seek(0, io.SeekStart)+f.Truncate(0)复位，避免文件无限增长干扰缓存行为 - 务必在循环体开头调用
f.Sync()（如需测持久化延迟），否则测的是 page cache 写入速度，不是落盘性能
bufio.Writer 缓冲区设多大才不拖慢小批量写入？
缓冲区不是越大越好。当单次写入量远小于缓冲区（如写 64B 数据配 4KB 缓冲），bufio.Writer 会因未满而不 flush，导致延迟堆积；但设太小（如 64B）又频繁 syscall，抵消缓冲收益。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 根据典型写入块大小设定：日志类（每条 ~200B）用
bufio.NewWriterSize(f, 2048)；配置文件批量写（每批 ~1KB）用4096 - 禁用自动 flush：不要依赖
Writer.WriteString后自动刷，显式调用w.Flush()控制时机 - 注意：Go 1.22+ 对
bufio.Writer的 small-write 优化生效，但仅限WriteString和Write直接调用，包装层（如自定义 logger）可能绕过该优化
内存映射（mmap）在 Go 文件读取中真能提效吗？
Go 标准库不直接暴露 mmap，需用 golang.org/x/sys/unix.Mmap。它对「随机读大文件」有优势，但对「顺序读中小文件」反而更慢——因为 mmap 触发 page fault 的开销 > 直接 Read 系统调用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 仅当满足全部条件时考虑 mmap：文件 > 100MB、读取跨度分散、且内存充足（mmap 占用 RSS，不计入 Go heap）
- 必须手动
unix.Munmap，否则泄露虚拟内存地址空间（尤其在 long-running service 中） - Windows 不支持
unix.Mmap，需用syscall.CreateFileMapping替代，跨平台成本高，除非 IO 是绝对瓶颈，否则不值得
文件 IO 基准测试最易被忽略的点：磁盘缓存状态。同一台机器连续跑两次 go test -bench=.，第二次结果可能快 5 倍——因为 OS page cache 已预热。每次测试前加 sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"（Linux）或重启进程并清空 /tmp，才能拿到稳定可比数据。
