热路径应避免频繁系统调用：用bufio.reader/writer批量读写，合理设置缓冲区大小（如4kb起点，按数据规律调整），复用buffer、慎用并发读单文件，优先用io.copybuffer定制缓冲并配合sync.pool复用切片。
热路径上减少系统调用，核心就一条：别让每次读写都陷进内核——用缓冲把零散操作聚合成批，再配合复用和预判。
bufio.NewReader 和 bufio.NewWriter 必须用，不能直接操作 *os.File
直接对 *os.File 调 Read() 或 Write()，每字节、每行、每小块都可能触发一次 read(2) 或 write(2)。热路径里这种开销会被放大成数量级差距。
- 逐行读日志？用
bufio.NewReader(f)+ReadString('\n')，不是f.Read()循环 - 写监控指标或审计日志？用
bufio.NewWriter(f)，且务必在Close()前显式w.Flush() - 同一
*os.File上别套多个bufio.Reader实例——缓冲区错位会导致丢数据或 panic
缓冲区大小不是越大越好，4KB 是起点，不是终点
默认 4KB 缓冲对多数场景够用，但盲目设成 1024 * 1024（1MB）反而有害：GC 扫描压力陡增、内存占用翻倍、SSD 吞吐几乎不涨。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 按数据块规律设：日志行平均长度 8KB？用
bufio.NewReaderSize(f, 64*1024)（64KB），让一次系统调用尽可能填满 buffer - 纯统计行数？
bufio.Scanner比Reader.ReadString更轻量，它复用内部 buffer 且跳过换行解析逻辑 - buffer 太小（如 128B）会高频 flush；太大（如 1MB）会让磁盘满等错误延迟暴露——直到
Flush()才报no space left on device
io.CopyBuffer 是大文件拷贝的确定性优化点
io.Copy 默认用 32KB buffer，但无法定制；热路径里拷 GB 级日志或归档包时，必须用 io.CopyBuffer(dst, src, buf) 控制缓冲行为。
- 缓冲切片
buf必须预先分配，且生命周期覆盖整个CopyBuffer调用 - 推荐
make([]byte, 64*1024)：匹配常见页大小，NVMe 盘实测比默认减少约 15% 系统调用 - 别在循环里每次都
make新切片——用sync.Pool复用，避免 GC 压力
并发读单个大文件反而拖慢吞吐，这点容易被忽略
SSD 上并发读多个独立文件（如分片日志）可能提速，但对单个 10GB 文件开 4 个 goroutine 分 offset 读，大概率因寻道加剧、队列打乱而降低整体吞吐。
- 真正值得并发的只有两类：多文件并行处理、或 mmap + 分段处理（随机访问场景）
- 顺序读取（如 ETL 流水线）老老实实用单 goroutine + 合理 buffer，更稳更快
- 若真要分段，得用
file.ReadAt()配合 offset 控制，绕过bufio的顺序预读污染 page cache
缓冲区不是万能胶，它解决的是“调用太碎”，不是“磁盘太慢”。热路径性能瓶颈常藏在 buffer 大小、复用方式、以及是否误用了并发这三处——调参前先用 strace -e trace=read,write 看一眼实际系统调用频次，比凭感觉设值靠谱得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
