bufio 包仅在需控制读写节奏、减少系统调用、处理行/分隔符、利用 UnreadRune/Peek 或应对慢源时才应使用;否则增加开销。
Go 的 bufio 包不是万能缓冲层,它只在你明确需要控制读写节奏、减少系统调用次数,或处理行/分隔符文本时才值得引入;盲目套用反而增加内存开销和逻辑复杂度。
bufio.Reader 而不是直接 io.Read
当你遇到以下情况之一时,bufio.Reader 才真正发挥作用:
Read 会导致大量 syscall.read,性能明显下降ReadString('\n') 或 ReadLine())或按分隔符(ReadBytes / ReadUntil)读取,底层 io.Reader 不提供这类语义UnreadRune 或 Peek —— 这些能力标准 io.Reader 完全没有反例:读一个 2MB 的本地 JSON 文件一次性解码?直接 os.ReadFile 或 io.ReadAll 更简单安全,加 bufio 只是多绕一层指针。
bufio.Scanner 和 bufio.Reader 怎么选Scanner 是封装更厚的行导向工具,适合“读行→处理→丢弃”场景;Reader 是更底层、更灵活的缓冲视图。别混用,也别强行替换。
Scanner 默认单行上限 64KB,超长行会报 "scanner token too long";改用 bufio.Reader.ReadLine() 或手动 ReadBytes('\n') 更可控Scanner.Split 支持自定义分隔逻辑(如按空格、按 JSON 对象边界),但必须自己管理缓冲区溢出;Reader 没有 Split,得靠 ReadBytes + 切片判断Scanner.Err() 只返回最后一次扫描错误;而 Reader.Read... 系列方法错误立即返回,调试路径更清晰Reader 的 Peek(1) + Discard(1) 组合比 Scanner 更直接scanner := bufio.NewScanner(file)
scanner.Split(bufio.ScanLines) // 注意:ScanLines 会丢掉 \n
for scanner.Scan() {
line := scanner.Text() // 注意:Text() 返回的是内部缓冲副本,不是 []byte
// ...
}
bufio.Writer 的 flush 时机和陷阱Writer 的核心价值是合并小写入、减少 write() 系统调用;但它不自动 flush,这点极易被忽略。
WriteString / Write 都不保证落盘,必须显式调 Flush(),尤其在写文件末尾、HTTP 响应头后、或作为协议帧结尾时gzip.Writer{Writer: bufio.NewWriter()}),要先 gzip.Close()(它会 flush 底层 writer),再 bufio.Flush() —— 顺序错会导致压缩流损坏bufio.Writer 包裹 ResponseWriter?别这么做。标准 http.ResponseWriter 已内置缓冲,额外包一层反
w := bufio.NewWriter(os.Stdout)
w.WriteString("hello")
w.WriteString(" world")
// 此时 "hello world" 还在内存缓冲里
w.Flush() // 必须这一句,否则可能看不到输出
默认 4KB 是通用折中值,但具体要根据使用场景调整:
Reader 缓冲提到 64KB–256KB,减少 read() 次数;但别超过 1MB,避免单次分配压力ReadLine() 被截断bufio.NewReaderSize(r, 1) —— 这等于没缓冲,还多一层函数调用开销缓冲区大小不是越大越好,它占用 goroutine 栈外堆内存,且影响 GC 压力;线上服务压测时记得监控 runtime.MemStats.HeapAlloc 是否异常增长。