bufio.NewReader 比 os.File.Read 快是因为它用内存缓冲区（默认4KB）合并多次小读取，减少系统调用，尤其处理小行时开销可降90%以上；但需注意缓冲区与底层连接生命周期匹配，避免 connection reset 错误。
bufio.NewReader 为什么比 os.File.Read 快
因为 os.File.Read 每次调用都触发一次系统调用，而 bufio.NewReader 在内存里维护一块固定大小的缓冲区（默认 4KB），把多次小读取合并成一次大读取。尤其读取大量小行（比如日志、CSV）时，系统调用开销能降 90% 以上。
常见错误现象：read: connection reset by peer 突然变多，其实是没处理好缓冲区和底层连接生命周期——bufio.Reader 不会自动关闭底层连接，你关早了，它还在缓存里读；关晚了，连接可能已被对端释放。
- 使用场景：逐行读文件、HTTP 响应体解析、TCP 流中按分隔符切消息
- 缓冲区大小不是越大越好：超过 64KB 后收益极小，还可能拖慢 GC；网络场景建议 4KB–32KB，文件场景可设到 256KB
- 注意
bufio.Scanner默认单行上限 64KB，超长行会直接报scanner: token too long，得用bufio.Reader.ReadLine或自定义SplitFunc
bufio.NewWriter 写文件卡住或丢数据？检查 Flush
bufio.NewWriter 的缓冲区只在满、显式调用 Flush 或关闭时才真正写入。忘记 Flush 是最常导致“写完了但文件空”或“程序退出后内容消失”的原因。
典型错误代码：w := bufio.NewWriter(f); w.WriteString("hello"); // 忘了 flush！ —— 这时内容还卡在内存里。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须配对：打开
bufio.NewWriter→ 写 →w.Flush()→ 关闭底层f.Close() - 别依赖
defer w.Flush()：如果w是局部变量，defer在函数返回时才执行，但若函数 panic，Flush可能不执行；更稳妥的是defer func() { w.Flush(); f.Close() }() - 网络写（如
net.Conn）更要小心：Flush失败意味着底层连接已断，此时再写会 panic，得提前检查err
bufio.Scanner 和 bufio.Reader 选哪个
看你要不要“按规则拆分”，而不是“要不要缓冲”。bufio.Scanner 是带预置分隔逻辑的 Reader 封装，适合读行、读空格分隔字段；bufio.Reader 是裸缓冲，适合精确控制读取边界（比如协议头+变长体）。
容易踩的坑：Scanner.Scan() 返回 true 只表示成功读到一个 token，不表示没错误；真正的错误要调用 Scanner.Err() 查，否则静默失败。
- 读纯文本日志、配置项：用
Scanner，简洁安全 - 解析二进制协议、HTTP/1.1 header/body 分界、需要 peek 下一个字节：必须用
Reader -
Scanner的Split函数不能返回负数长度，否则 panic；自定义分隔时，advance参数必须 data 长度
跨平台文件读写要注意缓冲区对齐吗
不用。Go 的 bufio 对所有平台一视同仁，缓冲区只是内存切片，不涉及磁盘扇区对齐或 mmap 页面边界。但 Windows 上 os.O_APPEND 和 bufio.Writer 有隐含冲突：Windows 要求 append 模式下每次 write 都带 seek 到末尾，而 bufio.Writer 的缓冲机制会打乱这个顺序，导致部分写入被覆盖。
- Windows 下追加写文件，别用
bufio.NewWriter+os.O_APPEND，直接用os.File.Write - Linux/macOS 没这个问题，但若程序需跨平台，统一用
os.O_CREATE | os.O_WRONLY | os.O_APPEND+ 直接Write更省心 - 网络场景完全不用考虑这个，TCP/IP 栈本身已做缓冲和重传，
bufio只管应用层吞吐
