默认4kb缓冲区在压测中表现差，因其导致系统调用频繁、上下文切换开销大；建议按场景选用64kb～256kb缓冲区以减少read()次数，但避免盲目设为1mb以防gc压力增大。
直接用 bufio.NewReaderSize 指定大小，别依赖默认的 4KB —— 对大文件或高吞吐场景，它会因系统调用太频繁拖慢整体性能。
为什么默认 4KB 缓冲区在压测中表现差
默认 bufio.NewReader 分配 4096 字节缓冲区，每次 Read 落到内核都要切换上下文、检查权限、更新文件 offset。这些开销在压测中会被放大，尤其当单次读取量远小于缓冲区（比如反复读 128 字节）时，syscall 频次飙升。
- 实测显示：读取 1GB 文件时，4KB 缓冲平均触发约 262k 次
read()系统调用；换成 64KB 后降到约 16k 次 - Linux 页大小通常为 4KB，64KB～256KB 是多数磁盘 I/O 场景的甜点区间
- 缓冲区大小不影响逻辑正确性，只改变 syscall 频次和内存占用
怎么设才合理：按场景选值，不是越大越好
盲目设成 1MB 不仅浪费内存，还可能让 runtime 把缓冲区分配到堆上，加重 GC 压力。关键看你的 I/O 模式：
- 逐行读文本（如日志、CSV）：设为「预期最长行长度 + 128」，避免
ReadString('\n')多次扩容 - 写入 HTTP 响应或日志：若平均消息体约 8KB，用
bufio.NewWriterSize(w, 8192) - 大文件顺序读（>100MB）：优先试
64 * 1024或128 * 1024，用strace -e trace=read验证 syscall 次数是否下降 - 纯流复制（如文件拷贝）：直接用
io.Copy，它内部已用 32KB 缓冲，且做零拷贝优化
常见错误：传参错、误信 O_DIRECT、滥用 Scanner
这几个坑踩一个，性能就打折扣：
- 传
bufio.NewReaderSize(file, 128)—— 过小反而更慢，比不加缓冲还糟 - 在
os.OpenFileflag 里加syscall.O_DIRECT—— Go 标准库不支持，会静默回退或报EINVAL - 用
bufio.Scanner读超长行但没调scanner.Buffer(make([]byte, 1 —— 默认 64KB 限制一到就 panic - 为每个短连接新建
bufio.Reader却不复用 —— 小对象逃逸堆，GC 频繁
别忘了验证：用工具看真实 syscall 和内存行为
调优不能靠猜。上线前至少做两件事：
- 用
strace -p $(pidof yourapp) -e trace=read,write观察实际系统调用次数和数据量 - 跑
go test -bench=. -benchmem对比不同缓冲大小下的BenchmarkAllocs和BenchmarkNsPerOp - 注意：
io.Copy默认 32KB 缓冲，如需更大，可包装io.Reader提前设置，而非硬改底层
缓冲区调优的本质是平衡 syscall 开销与内存成本，而最常被忽略的是——你其实不需要自己管理缓冲，只要明确场景该用 io.Copy、bufio.Scanner 还是裸 Read，就已经避开了 80% 的性能陷阱。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
