bufio包通过内存缓冲减少系统调用次数而非加速读写；WriteString后需显式Flush才能写入磁盘；ReadString遇EOF可能报错，须检查err；缓冲区大小应依场景调整；Reader/Writer混用同一文件需避免竞态。
Go 标准库的 bufio 包不是为了“加速”读写，而是为了解决小数据量频繁系统调用带来的开销——直接对 *os.File 每次 Write 或 Read 都可能触发一次系统调用；bufio.Writer 和 bufio.Reader 通过内存缓冲层批量处理，显著降低 syscall 次数。
为什么 WriteString 后文件没内容？必须调用 Flush
bufio.Writer 的写入默认只进内存缓冲区，不自动刷到磁盘。常见现象：程序结束但文件为空，或只看到部分数据。
- 每次
Write/WriteString只填充内部buf，未触发实际写入 - 缓冲区满（默认 4KB）时会自动
Flush，但不能依赖这个行为 - 程序退出前必须显式调用
w.Flush()，否则缓冲区残留数据丢失 - 如果后续还要写，可复用
Writer；若确定写完，defer w.Flush()是安全习惯
file, _ := os.Create("out.txt")
w := bufio.NewWriter(file)
w.WriteString("hello")
w.WriteString(" world")
w.Flush() // 必须！否则文件里什么都没有
file.Close()
Reader 的 ReadString('\n') 为什么会阻塞或 panic？
bufio.Reader.ReadString 会一直读直到遇到指定分隔符（如 '\n'），若输入流提前 EOF 且未找到分隔符，返回 err == io.EOF 或 err == bufio.ErrBufferFull；若忽略错误直接取 string，可能 panic 或读出脏数据。
- 永远检查返回的
err，不要假设一定能读到换行符 - 读取二进制或无固定分隔符的数据，改用
ReadBytes或ReadSlice - 大文件逐行读时，
Scanner更安全（它内置处理了缓冲和边界），ReadString更适合协议解析等可控场景 - 缓冲区太小（如
bufio.NewReaderSize(r, 16)）可能导致单行超长时失败
f, _ := os.Open("log.txt")
r := bufio.NewReader(f)
for {
line, err := r.ReadString('\n')
if err == io.EOF {
if len(line) > 0 { // 最后一行可能没换行符
fmt.Println("last:", line)
}
break
}
if err != nil {
log.Fatal(err)
}
fmt.Print("line:", line)
}
Writer 的缓冲区大小怎么设？太大太小都不好
默认缓冲区是 4096 字节，适用于大多数文本日志、HTTP 响应等场景。但需根据使用模式调整：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 高频小写（如每毫秒写一条 JSON 日志）：增大缓冲（如 64KB），减少 flush 次数和锁竞争
- 低频大写（如导出一个 10MB CSV）：缓冲意义不大，甚至浪费内存；可设为 0（此时退化为直接写底层
io.Writer） - 实时性要求高（如 telnet 回显）：设小缓冲（如 128B）或直接禁用（
bufio.NewWriterSize(w, 0)），避免延迟 - 注意：缓冲区大小必须 > 0 才启用缓冲；等于 0 时所有方法直通底层，
Flush变成空操作
Reader/Writer 能否混用同一个 *os.File？要小心竞态
可以共用一个 *os.File，但必须确保**没有并发读写**，否则文件偏移量错乱、数据覆盖、panic 都可能发生。
- 同一 goroutine 内顺序读再写（或写再读），需手动
Seek重置位置，否则读写位置不同步 - 多个 goroutine 分别读/写同一文件：必须加锁（如
sync.Mutex）保护Reader/Writer实例，或改用 channel 协调 - 更推荐方案：读写分离——一个 goroutine 专读 + channel 发送，另一个专写；或用
io.Pipe解耦 - 不要把
bufio.NewReader(os.Stdin)和fmt.Scanln混用，后者内部也用缓冲，会互相干扰
缓冲的本质是权衡：用内存换 syscall 次数，用可控延迟换吞吐。真正难的不是调用 NewWriter，而是判断什么时候该 flush、什么时候该扩容、以及在并发下谁负责维护文件偏移——这些细节不处理，缓存反而变成 bug 温床。
