go文件缓冲区需按读写模式、数据特征和错误处理匹配调优：按行读设略大于最长行，大文件顺序读用64kb–128kb，网络用4kb–32kb；scanner须预设buffer防panic，writer务必显式flush防丢失。
Go 文件缓冲区不是“设了就快”，而是得看读写模式、数据特征和错误处理是否匹配——盲目调大缓冲区反而可能 OOM 或延迟升高。
bufio.NewReaderSize 和 bufio.NewWriterSize 的缓冲区大小怎么选
缓冲区大小不是越大越好，也不是默认 4096 就够用。关键看你的数据单元大小和访问模式：
- 按行读文本（如日志、CSV）：按单行最大预期长度 + 128 字节设置，比如最长行约 8KB，就用
bufio.NewReaderSize(file, 64*1024) - 顺序读大文件（>100MB）：64KB–128KB 效果明显，
strace -e trace=read可验证系统调用次数下降 - 网络响应或 HTTP header 解析：4KB–32KB 更稳，兼顾延迟与内存占用
- 别设成
math.MaxInt32或 1MB 以上：不可控输入下易触发 OOM，尤其 Scanner 默认上限才 64KB
bufio.Scanner 超长行 panic 怎么避免
scanner: token too long 不是文件太大，是某一行超出了缓冲区上限，而 Scanner 默认不返回错误，直接 panic —— 这个 panic 无法 recover，服务可能挂掉。
- 必须在
scanner.Scan()前调用scanner.Buffer(make([]byte, 64*1024), maxLen)，例如支持 1MB 行：scanner.Buffer(make([]byte, 64*1024), 1024*1024) -
scanner.Text()返回的字符串底层复用缓冲区，下次Scan()就覆盖；要长期保存，得显式拷贝：string(scanner.Bytes())或append([]byte{}, scanner.Bytes()) - 输入不可控时（如用户上传日志），别用 Scanner；改用
reader.ReadBytes('\n')或自己循环Read()+ 固定切片扫描换行符更安全
bufio.Writer 写完文件却为空？大概率没 Flush
bufio.Writer 的数据只在三种情况下真正落盘：缓冲区满、显式调 w.Flush()、或 w.Close()。但 Close() 不保证成功，失败也不报错。
- 不能只写
defer w.Close()—— 如果程序 panic 或提前 return，Flush()根本没执行 - 安全写法是：
defer func() { _ = w.Flush(); f.Close() }() - 日志类高频写场景慎用超大缓冲（如 1MB）：crash 时最多丢 1MB 数据，且延迟高；建议 32KB–256KB 平衡
- 别把
bufio.Writer传给io.Copy：它内部已用 32KB 缓冲 + 零拷贝优化，再包一层反而冗余甚至卡死
缓冲区调优最常被忽略的点：不是“设多大”，而是“谁来控制刷盘时机”——Flush() 漏掉，数据就静默丢失；Buffer() 设错，程序就 panic；混用 Reader 和 Scanner，读位置还会错乱。实测比理论更重要，压测时记得用 go tool pprof -http=:8080 看系统调用占比变化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
