缓冲大小需匹配数据访问模式：日志行读取用4KB，大文件拷贝用32–64KB，小配置文件不加缓冲，网络代理两端统一8KB；Scanner需显式设token上限，避免panic；应通过runtime.ReadMemStats验证并复用缓冲内存。
缓冲大小影响 bufio.Reader 和 bufio.Writer 的实际性能
Go 标准库的 bufio 包不会自动适配文件大小或磁盘类型来调整缓冲区，它完全依赖你传入的 size 参数。过小（如 1）退化为无缓冲，每次 Read 都触发系统调用；过大（如 100MB）浪费内存且可能拖慢 GC。真实瓶颈往往不在吞吐量，而在单次分配延迟和内存复用效率。
常见场景下的推荐值与依据
不同用途对缓冲区敏感度差异很大，硬套“4KB”或“64KB”反而容易出问题：
- 读取日志行（
ReadString('\n')或ReadLine()）：优先选4096（4KB）。太小会导致频繁切片扩容；太大让单行匹配后剩余数据滞留缓冲区，影响下一次读取的响应性 - 大文件顺序拷贝（
io.Copy）：用32768（32KB）或65536（64KB）。这是 Linux 默认页缓存和多数 SSD 顺序读最佳块大小的交集，实测比4KB快 15–25% - 小配置文件解析（
json.Decoder/toml.Decode）：直接用os.File，不加bufio。这类操作本身 CPU-bound，加缓冲层只增开销 - 网络代理类流式处理（边读边写）：必须两端缓冲一致，建议统一设为
8192（8KB），避免 Reader 提前耗尽、Writer 等待写满才 flush 导致卡顿
bufio.Scanner 的缓冲是特例，不能直接设大小
bufio.Scanner 内部用的是动态切片，其 Scan() 行读取行为受 MaxScanTokenSize 限制，默认仅 64 * 1024（64KB）。如果遇到超长行（如 minified JSON 单行），会直接报错 "bufio.Scanner: token too long"。此时必须显式调大：
scanner := bufio.NewScanner(file) scanner.Buffer(make([]byte, 64*1024), 10*1024*1024) // 第二个参数才是最大 token size
注意：第一个参数是初始底层数组，第二个才是上限；两个值不等时，内部会按需扩容，但不会超过第二个值。
立即学习“go语言免费学习笔记（深入）”；
用 runtime.ReadMemStats 验证缓冲是否合理
别猜，直接看内存行为。在关键路径前后调用：
var m runtime.MemStats
runtime.ReadMemStats(&m)
log.Printf("HeapAlloc = %v KB", m.HeapAlloc/1024)如果每次处理 10MB 文件，HeapAlloc 增长远超 10MB（比如到 30MB+），说明缓冲区导致大量临时切片逃逸到堆上。这时应降低缓冲大小，或改用 io.CopyBuffer 手动复用同一块内存：
buf := make([]byte, 32768) io.CopyBuffer(dst, src, buf)
这种写法能确保整个过程只分配一次 buf，后续全部复用，对 GC 更友好。
缓冲大小不是越接近硬件块大小就越优，真正关键的是匹配你的数据访问模式和内存生命周期。很多人忽略 scanner.Buffer() 的第二个参数，结果线上服务突然因某条超长日志行 panic，这种故障最难复现。
