推荐 bufio.newreadersize 缓冲区设为 64kb（64×1024），因其在吞吐、内存与页缓存对齐间取得最佳平衡；过小导致系统调用频发，过大引发 gc 压力且无收益。
bufio.NewReaderSize 的缓冲大小怎么设才不踩坑
默认 bufio.NewReader 用 4KB 缓冲区，对大文件顺序读就是性能杀手——每次 Read 都触发一次系统调用，上下文切换开销在压测中直接放大。实测显示，64KB 缓冲比 4KB 提升 15–25% 吞吐，但不是越大越好。
- 过小（如
128）退化为无缓冲，syscall 频次爆炸 - 过大（如
1024*1024）浪费内存，GC 扫描压力上升，且超过页缓存对齐收益归零 - Linux 页大小是 4KB，64KB～256KB 是多数 SSD 和磁盘的甜点区间，推荐从
64*1024起步实测 - 别硬套“统一值”：日志行读取用
4096，网络代理流用8192，小配置文件干脆不用bufio
io.Copy 和 io.ReadAll 的吞吐差异到底在哪
io.ReadAll 看似“一次读完更快”，实则高压下容易 OOM 或 GC 毛刺；io.Copy 配合合理缓冲更稳，因为它是流式搬运，不囤积全部数据。
-
io.Copy内部默认用 32KB 缓冲，可通过包装bufio.NewReaderSize提前设更大值（如64*1024） -
io.ReadAll必须全量进内存，压测时易触发 STW 停顿，尤其读 GB 级文件 - 若必须全读（如校验哈希），务必加
io.LimitReader(f, maxBytes)，防恶意超长输入 - 压测吞吐指标（QPS/MBps）时，目标写入用
io.Discard，避免内存膨胀干扰结果
Scanner 的缓冲不是 size 参数决定的
bufio.Scanner 的缓冲行为和 bufio.Reader 完全不同：它不靠传入 size 控制，而是由 scanner.Buffer() 的第二个参数限制最大 token 长度。
- 默认
MaxScanTokenSize是64 * 1024，遇到单行长 JSON 直接 panic："bufio.Scanner: token too long" - 调用
scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)——第一个参数是初始底层数组，第二个才是上限 - 即使设了大上限，超长行仍会触发切片扩容，频繁分配影响 GC；真要处理超长行，考虑改用
bufio.Reader.ReadLine() - 按行读日志时，4KB 初始 buffer + 合理上限（如
1024*1024）比盲目堆内存更可靠
O_DIRECT 在 Go 里基本没法用
别在 os.OpenFile 里加 syscall.O_DIRECT——Go 标准库不支持，runtime 不保证 buffer 对齐，大概率静默回退或报 EINVAL。
-
os.File底层仍走read()/write()，绕不过内核页缓存 - 真要 bypass page cache，得用
syscall.Open+ 手动对齐内存 +syscall.Read，但跨平台难、维护成本高 - 压测发现磁盘 I/O 瓶颈，优先调大
bufio缓冲区，而不是硬上O_DIRECT - SSD 随机读场景下，页缓存反而帮大忙；真正受益
O_DIRECT的是数据库类应用，有完整 buffer 对齐和生命周期管理
缓冲区大小不影响逻辑正确性，只改变 syscall 频次、内存占用和 GC 行为。最容易被忽略的是：同一份代码在不同访问模式（顺序读 vs 行扫描 vs 小文件高频读）下，最优缓冲值可能差一个数量级。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
