64kb是ssd顺序读的较优缓冲区大小，日志/cvs按最长行+128字节设定，机械盘用32kb，网络响应用64–128kb；scanner需预设buffer防超长行，写入后必须flush，scan()后须检查err()。
bufio.NewReaderSize 缓冲区设成多大才不浪费又不卡顿
默认 4KB 在多数小文件或交互式场景够用，但一碰日志、CSV 或归档解析就明显拖后腿——strace -e trace=read 一跑，read() 调用频次高得反常，吞吐上不去。关键不是“越大越好”，而是让缓冲区大小和底层设备预读行为对齐。
- SSD 顺序读（如日志归档、JSON 流）：优先试
64 * 1024；实测在 NVMe 上是吞吐与延迟的较优平衡点 - 机械盘或高并发小文件（比如同时开几十个日志句柄）：改用
32 * 1024，避免单次read()阻塞太久 - 网络响应体落盘（如 HTTP body 写文件）：
64 * 1024到128 * 1024更稳，但若 dst 是 TLS 连接，过大缓冲可能触发多次Write()，得实测 - 别设
math.MaxInt32或盲目上1024 * 1024：不可控输入下容易 OOM，GC 压力也会上升
Scanner 报 scanner: token too long 怎么快速定位和修复
这不是文件太大，是某一行超长（比如嵌了 base64 的日志），撑爆了默认 64KB 缓冲区。错误发生在 scanner.Scan() 内部，不查 scanner.Err() 就捕获不到，程序可能静默跳过后续所有行。
- 必须提前调
scanner.Buffer(make([]byte, 64*1024), max)，例如支持 1MB 行：scanner.Buffer(make([]byte, 64*1024), 1024*1024) -
scanner.Text()返回的字符串底层复用缓冲区，下次Scan()就覆盖；需长期保存时，得显式拷贝：string(scanner.Bytes())或append([]byte{}, scanner.Bytes()) - 如果输入不可控（如用户上传），别依赖
Scanner；换reader.ReadBytes('\n')或自己用Read()+ 固定切片循环扫描换行符更安全
io.CopyBuffer 复用缓冲时为什么没提速
常见错因是传了数组字面量而不是切片，导致每次调用都 new 新内存，完全失去复用意义。
- 正确写法：
buf := bufPool.Get().([]byte); io.CopyBuffer(dst, src, buf[:0]); bufPool.Put(buf) - 错误写法：
io.CopyBuffer(dst, src, [4096]byte{})——数组字面量每次触发新分配 - 缓冲建议大小：
make([]byte, 0, 128*1024)适合 SSD 场景；网络转发用64 * 1024到128 * 1024更合适 - 注意：若
dst不支持部分写（如某些 TLS 封装），过大缓冲反而增加 Write 次数，需实测验证
什么时候该绕过 bufio 直接用 f.Read
不是所有场景都适合加缓冲层。当 bufio 的抽象带来偏移错乱、长度不确定性或额外 GC 开销时，就得退回去直连系统调用。
- 定长二进制记录（如 protobuf 帧头、固定 16 字节 header）：直接复用
[]byte调f.Read(buf)，避免ReadString或ReadBytes的长度不确定性 - 多层
bufio.Reader套用同一*os.File：底层文件偏移不同步，会跳字节或重复读 - 高频小文件拷贝（如微服务间中转）：
io.Copy内部用 32KB 临时缓冲，每次 new 切片，GC 压力大；此时应自己管理缓冲池 +io.CopyBuffer - 随机访问（如按 offset 查找日志条目）：缓冲无意义，考虑
mmap或file.Seek()后单次读
缓冲区调优最易被忽略的一点：它从来不是孤立参数。它和底层文件偏移、系统预读大小、甚至 CPU L3 cache line 对齐都有关联。设完值不验证，等于白调。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
