bufio.NewReaderSize 更快是因为默认4KB缓冲区导致系统调用频繁，增大至64KB～256KB可减少上下文切换开销；O_DIRECT在Go中不被标准库支持；io.Copy比io.ReadAll更稳；GOMAXPROCS对文件I/O提升有限。
bufio.NewReaderSize 为什么比默认缓冲区快
因为默认的 bufio.NewReader 只分配 4KB 缓冲区，对大文件或高吞吐 I/O 场景来说，系统调用太频繁。每次 Read 落到内核，都要切换上下文、检查权限、更新 offset——这些开销在压测中会被放大。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
bufio.NewReaderSize显式指定缓冲区，比如bufio.NewReaderSize(file, 64*1024)（64KB） - 常见错误：传入过小值（如 128）反而更慢；过大（如 1MB）可能浪费内存且无收益
- Linux 下页大小通常是 4KB，64KB～256KB 是多数场景的甜点区间
- 注意：缓冲区大小不影响读取逻辑正确性，只影响 syscall 频次和内存占用
os.OpenFile + O_DIRECT 在 Go 里基本没用
O_DIRECT 本意是绕过内核页缓存，但 Go 的 os.File 底层仍依赖 read()/write() 系统调用，且 runtime 不保证 buffer 对齐、不处理对齐后的内存分配——直接启用会触发 EINVAL 错误或静默回退到普通路径。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别在
os.OpenFile的flag里加syscall.O_DIRECT，Go 标准库不支持 - 真要绕过 page cache，得用
syscall.Open+ 手动对齐 buffer +syscall.Read，但维护成本高、可移植性差 - 压测时发现磁盘 I/O 瓶颈，优先调大
bufio缓冲区，而不是硬上O_DIRECT
压测时 ioutil.ReadAll 和 io.Copy 比较结果反直觉
ioutil.ReadAll（已弃用，现为 io.ReadAll）会一次性把全部内容读进内存，看似“快”，但压测中容易触发 GC 压力或 OOM；而 io.Copy 配合合理缓冲区，吞吐更稳、延迟毛刺更少。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 压测吞吐量（QPS/MBps）时，用
io.Copy(dst, src)+ 自定义bytes.Buffer或io.Discard，避免内存膨胀 - 如果必须全读（比如校验哈希），至少限制最大长度：
io.LimitReader(f, maxBytes) - 注意
io.Copy默认使用 32KB 内部缓冲区，可通过包装io.Reader提前设置更大缓冲区 - 别信“一次读完更快”的直觉——内存带宽和 GC 停顿在高压下才是瓶颈
runtime.GOMAXPROCS 和文件并发读的关系很弱
文件读取是 I/O 密集型操作，不是 CPU 密集型。提高 GOMAXPROCS 对单个磁盘的顺序读几乎没有帮助，反而可能因 goroutine 调度开销增加延迟抖动。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 保持
GOMAXPROCS为默认（等于 CPU 核数），除非你同时做大量解码/计算 - 真正提升并发读性能的是：拆分文件、用多个
*os.File实例、配合sync.Pool复用bufio.Reader - SSD 上多路并发读有效；HDD 上过多并发反而因寻道变慢
- 压测前先用
iostat -x 1看%util和await，判断是 CPU 瓶颈还是磁盘瓶颈
缓冲区不是越大越好，也不是越小越省；它和你的硬件、数据分布、压测目标强耦合。跑一次 pprof 看 runtime.read 占比，比凭经验调参靠谱得多。
