bufio 包仅在需控制读写节奏、减少系统调用、处理行/分隔符、利用 UnreadRune/Peek 或应对慢源时才应使用；否则增加开销。
Go 的 bufio 包不是万能缓冲层，它只在你明确需要控制读写节奏、减少系统调用次数，或处理行/分隔符文本时才值得引入；盲目套用反而增加内存开销和逻辑复杂度。
什么时候该用 bufio.Reader 而不是直接 io.Read
当你遇到以下情况之一时，bufio.Reader 才真正发挥作用：
- 频繁读取小块数据（比如逐字符、逐行解析日志），直接调
Read会导致大量syscall.read，性能明显下降 - 需要按行（
ReadString('\n')或ReadLine()）或按分隔符（ReadBytes/ReadUntil）读取，底层io.Reader不提供这类语义 - 源 Reader 本身很慢（如网络连接、磁盘文件），而你又不希望每次读都等 I/O，缓冲能平滑延迟
- 需要
UnreadRune或Peek—— 这些能力标准io.Reader完全没有
反例：读一个 2MB 的本地 JSON 文件一次性解码？直接 os.ReadFile 或 io.ReadAll 更简单安全，加 bufio 只是多绕一层指针。
bufio.Scanner 和 bufio.Reader 怎么选
Scanner 是封装更厚的行导向工具，适合“读行→处理→丢弃”场景；Reader 是更底层、更灵活的缓冲视图。别混用，也别强行替换。
立即学习“go语言免费学习笔记（深入）”；
-
Scanner默认单行上限64KB，超长行会报"scanner token too long"；改用bufio.Reader.ReadLine()或手动ReadBytes('\n')更可控 -
Scanner.Split支持自定义分隔逻辑（如按空格、按 JSON 对象边界），但必须自己管理缓冲区溢出；Reader没有 Split，得靠ReadBytes+ 切片判断 -
Scanner.Err()只返回最后一次扫描错误；而Reader.Read...系列方法错误立即返回，调试路径更清晰 - 如果要边读边修改内容（比如跳过 BOM、过滤注释），
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，这点极易被忽略。
- 写入未满缓冲区（默认 4KB）时，数据只存于内存，不会落盘或发到网络 —— 如果程序 panic 或提前 exit，这部分数据就丢了
-
WriteString/Write都不保证落盘，必须显式调Flush()，尤其在写文件末尾、HTTP 响应头后、或作为协议帧结尾时 - 嵌套使用时（比如
gzip.Writer{Writer: bufio.NewWriter()}），要先gzip.Close()（它会 flush 底层 writer），再bufio.Flush()—— 顺序错会导致压缩流损坏 - HTTP handler 中用
bufio.Writer包裹ResponseWriter？别这么做。标准http.ResponseWriter已内置缓冲，额外包一层反而干扰 HTTP/2 流控
w := bufio.NewWriter(os.Stdout)
w.WriteString("hello")
w.WriteString(" world")
// 此时 "hello world" 还在内存缓冲里
w.Flush() // 必须这一句，否则可能看不到输出
缓冲区大小设多少才合理
默认 4KB 是通用折中值，但具体要根据使用场景调整：
- 读大文件（>100MB）且按行处理？把
Reader缓冲提到 64KB–256KB，减少read()次数；但别超过 1MB，避免单次分配压力 - 写日志到 SSD？4KB 足够，更大的缓冲反而让日志延迟更明显（flush 不及时）
- 网络协议解析（如 Redis RESP、HTTP chunked）？缓冲设为最大单帧长度 + 一些余量，比如 RESP 协议建议至少 8KB，防止
ReadLine()被截断 - 千万别用
bufio.NewReaderSize(r, 1)—— 这等于没缓冲，还多一层函数调用开销
缓冲区大小不是越大越好，它占用 goroutine 栈外堆内存，且影响 GC 压力；线上服务压测时记得监控 runtime.MemStats.HeapAlloc 是否异常增长。
