结论：用bufio.scanner读文本文件，用bufio.writer写且必须调flush()；一次性读大文件时勿套bufio.reader。scanner适合按行处理文本，readstring适合精确控制分隔符；scanner默认单行上限64kb，超长返回errtoolong。
直接说结论：用 bufio.Scanner 读文本文件，用 bufio.Writer 写且必须调 Flush()；别在一次性读大文件时套 bufio.Reader，那反而慢。
什么时候该用 bufio.Scanner 而不是 bufio.Reader.ReadString
多数按行处理文本（日志、配置、CSV）时，Scanner 更简洁、默认性能更好，且自带行边界处理；ReadString('\n') 适合需要精确控制分隔符或混合读取场景（比如一行里还要切字段）。
-
Scanner默认单行上限 64KB，超长会返回scanner.ErrTooLong错误——不是 panic，但容易被忽略，得用sc.Buffer(make([]byte, 64*1024), 1 手动扩容 -
Scanner.Text()返回string，如果后续要转[]byte，不如直接用sc.Bytes()避免拷贝 - 别和
bufio.Reader混着用同一个文件句柄：它们各自维护缓冲区，位置不同步，会漏数据或重复读
bufio.Writer 写文件不 Flush() 就丢数据
缓冲写本质是把数据先攒在内存里，等满或手动刷才落盘。Writer.Close() 不保证 flush，尤其当底层是 io.Writer 接口（如网络连接）时，Close() 可能直接丢弃缓冲区内容。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须显式调
w.Flush()，且检查错误：if err := w.Flush(); err != nil { /* handle */ } - 想实时写（如日志），每条后都
Flush()；吞吐优先就靠缓冲区自动触发，但程序退出前务必 flush - 用
bufio.NewWriterSize(file, 64*1024)加大缓冲区，对高频率小写入更有效；默认 4096 字节够日常用
哪些情况不该用 bufio 反而更慢
缓冲机制只在「频繁小块 I/O」时省系统调用；一次性操作加缓冲纯属多此一举，还多一次内存拷贝。
- 用
io.ReadAll(f)或os.ReadFile()读整个小文件，别包装bufio.Reader - 用
io.Copy(dst, src)复制文件，src/dst 直接传*os.File，套bufio.Reader/Writer反而降低性能 - 读二进制或非 UTF-8 数据，优先用
file.Read(buf)或io.ReadFull，bufio.Reader的文本导向方法（如ReadString）可能误判边界
真正容易被忽略的点是：缓冲区大小和业务实际匹配比“用了 bufio”更重要；还有就是 Scanner 和 Reader 绝不能共享底层 reader，这点一错就静默出错，查起来极费时间。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
