ReadString('\n') 性能差是因默认4KB缓冲区与长行不匹配，致频繁syscall；应按行长分布设缓冲（如8KB行长用64KB），并检查bufio.ErrTooLong防静默截断。
默认 4KB 缓冲区在读大文本时 syscall 过多，吞吐低；必须按行长特征调大缓冲区，否则 ReadString('\n') 会反复填缓冲、频繁系统调用，性能比 Scanner 还差。
bufio.Reader.ReadString('\n') 为什么比预期慢
ReadString('\n') 内部会不断调用底层 Read() 填充缓冲区，直到遇到 '\n' 或 EOF。如果缓冲区太小（如默认 4KB），而日志行平均长度 8KB，它每读一行就要触发 2–3 次系统调用——这不是 Go 慢，是缓冲没对齐业务数据特征。
- 实测：64KB 缓冲 vs 4KB 缓冲读 10GB 日志，
read()系统调用次数下降 6 倍，总耗时减少约 40% - 缓冲区过大会拖慢响应：设成 1MB 后，首行延迟明显升高，且 GC 压力上升（尤其短生命周期的 reader）
- 超长行仍可能 OOM：ReadString 不限制单行上限，遇到缺失换行符的 base64 块，会持续分配内存直至崩溃
缓冲区大小怎么设才合理
不是拍脑袋定 64KB 或 1MB，而是看你的行长分布和场景约束：
- 日志/CSV 类文本：按「预估最长行长度 + 128 字节」设缓冲，例如最长行约 8KB → 用
bufio.NewReaderSize(file, 64*1024) - 纯顺序流式解析（不关心行边界）：64KB–128KB 最稳，再大收益递减，内存峰值翻倍
- 需处理末行无换行符的情况：优先用
reader.ReadBytes('\n')，它返回[]byte不做 UTF-8 解码，且能区分io.EOF和真实错误 - 输入不可控（如用户上传）：别依赖 ReadString；改用固定切片 +
reader.Read(buf)循环扫描换行符，自己控制内存上限
ReadString('\n') 的隐藏陷阱
它看似简单，但错误处理和边界行为极易出错：
立即学习“go语言免费学习笔记（深入）”；
- 返回的字符串是新分配的，但底层仍经过 UTF-8 解码 —— 如果文件含非法编码字节，会返回
err != nil且line是已解码部分，容易漏数据 - 遇到超长行不报错，只在最后返回
bufio.ErrTooLong，但很多代码只检查err == io.EOF，导致静默失败 - 无法跳过前 N 字节或 Peek 下几个字节 —— 若需协议解析（如 HTTP header/body 分界），必须换
bufio.Reader配合Peek()和Discard() - 不要对同一文件句柄反复创建新 reader：每次 new 都分配缓冲，应复用 reader 实例或用
reader.Reset()
什么时候该放弃 ReadString，改用更底层方式
当出现以下任一情况，ReadString('\n') 就不再是“够用”，而是隐患源：
- 需要保留原始字节（避免 UTF-8 解码开销或损坏二进制段），用
reader.ReadBytes('\n')或reader.ReadLine() - 行尾可能是
"\r\n"且需兼容 Windows 日志，ReadString('\n')会把\r留在行内，得手动 trim，不如ReadLine()自动处理 - 最后一行不确定是否有换行符，
ReadString在 EOF 时若缓冲区有残留内容，不会自动返回，必须额外判断len(line) > 0 - 要统计某字段出现次数且逻辑简单，直接用
scanner.Scan()+scanner.Bytes()更省内存 —— 它复用缓冲，不分配新字符串
缓冲区调优不是一劳永逸的事，关键在于匹配你的真实行长分布；最常被忽略的是：没在循环后检查 err 是否为 bufio.ErrTooLong，结果超长行被静默截断，问题在线上跑几天才暴露。
