os.read 慢因频繁系统调用导致上下文切换开销大；bufio.reader 通过默认4096字节缓冲区一次读多字节、减少syscall次数来提速，尤其适合逐行或小块读场景。
为什么直接用 os.Read 会慢，而 bufio.Reader 能提速
底层系统调用（如 read(2)）每次都要陷入内核，频繁小读取会导致大量上下文切换和 syscall 开销。而 bufio.Reader 在用户态维护一块固定大小的缓冲区（默认 4096 字节），一次系统调用读入多字节，后续 Read、ReadString、Scanln 等操作都从内存缓冲里取，大幅减少 syscall 次数。
注意：它不改变总 I/O 量，只优化调用频次；对大块连续读（如 >1MB 文件）提升有限，但对逐行、逐 token、小块读场景效果显著。
- 默认缓冲区大小是
bufio.DefaultBufSize（4096），可传入自定义大小，比如处理超长日志行时设为64 * 1024 - 缓冲区不是越大越好——过大会增加内存占用，且首次填充延迟更明显；一般
8KB–64KB是较稳妥的选择 -
bufio.Reader不是线程安全的，多个 goroutine 并发读同一实例需加锁或用各自副本
bufio.Scanner 和 bufio.Reader 该选哪个
Scanner 是更高层封装，专为「按行/按分隔符切分文本」设计；Reader 更通用，支持任意字节读取、Peek、Discard 等精细控制。性能上 Scanner 略快（内部也用 Reader，但做了更多预分配和状态缓存），但灵活性差。
常见误用：用 Scanner 读二进制或超长无换行数据——它默认单行上限 64KB，超出会报 "scanner token too long" 错误。
立即学习“go语言免费学习笔记（深入）”；
- 选
Scanner：读纯文本、按行处理（如配置文件、日志）、不关心超长行 - 选
Reader：需要Peek(1)判断下一个字节、读固定长度头、混合文本与二进制、自定义分隔符逻辑 - 若需突破
Scanner行长限制，调用scanner.Buffer(make([]byte, 64*1024), 1 手动扩容
写入侧：bufio.Writer 的刷新时机与陷阱
bufio.Writer 把写操作暂存在缓冲区，直到缓冲满、显式 Flush() 或关闭时才真正调用 write(2)。这意味着：不 Flush() 就 Close()，最后一段数据可能丢失；而频繁 Flush() 又抵消了缓冲意义。
典型错误：在循环中每写一行就 Flush()，等价于没缓冲。
- 标准做法：写完所有内容后调一次
Flush()；或在关键断点（如写完一个完整消息体）后刷新 - 若底层
io.Writer是网络连接（如net.Conn），注意Flush()会阻塞直到数据发出，超时需自行控制 -
Writer的缓冲区也是可配置的，小缓冲（如512）适合低延迟交互，大缓冲（如128KB）适合批量写入 - 调用
Writer.Reset()可复用实例，避免反复 new 分配
真实易错点：缓冲区生命周期与底层 io.Reader/Writer 关系
bufio.Reader/Writer 是装饰器模式，它们持有对原始 io.Reader/Writer 的引用，但不管理其生命周期。常见崩溃场景：提前 Close() 底层文件或连接，再调用 bufio 方法，会触发 "use of closed network connection" 或类似 panic。
另一个隐形问题：多个 bufio.Reader 包裹同一个文件，各自维护独立缓冲，导致读位置错乱（因为底层 os.File 的 offset 被其中一个 reader 移动后，另一个并不知情）。
- 始终确保
bufio实例的生命周期 ≤ 底层io对象 - 不要对同一底层资源创建多个
bufio实例，除非你明确控制读写顺序和 offset - 使用
io.MultiReader或io.TeeReader等组合器时，注意它们与bufio的嵌套顺序——缓冲应在最外层，否则中间层可能破坏流语义
