bufio.reader不是goroutine安全的，多个goroutine同时调用其read方法会导致数据竞争和未定义行为；必须通过外部同步机制（如互斥锁、channel或单goroutine串行读取）确保同一实例仅被一个goroutine访问。
bufio.reader不是goroutine安全的，多个goroutine同时调用其read方法会导致数据竞争和未定义行为；必须通过外部同步机制（如互斥锁、channel或单goroutine串行读取）确保同一实例仅被一个goroutine访问。
bufio.Reader 是 Go 标准库中用于带缓冲读取的核心类型，它通过内部字节切片（buf）和读取位置指针（rd, r, w 等字段）提升 I/O 效率。但其设计目标是单 goroutine 使用场景——所有公开方法（如 Read, ReadByte, ReadString, Peek, Discard）均会修改内部状态，尤其是读取偏移量 r 和缓冲区填充状态。例如，Read(p []byte) 在返回前会更新 r += n，而 fill() 操作则重置 r = 0 并移动 w。若两个 goroutine 并发调用 Read，可能引发以下问题：
- 竞态读取：goroutine A 读到一半时被调度，goroutine B 调用 fill() 清空并重填缓冲区，导致 A 继续读取脏数据或越界；
- 偏移错乱：r 字段非原子更新，造成读取位置丢失或重复读取；
- panic 风险：内部切片操作（如 buf[r:w]）在竞态下可能触发 index out of range。
✅ 正确做法示例：
方案一：使用 sync.Mutex 保护（适用于共享 reader 的多任务场景）
var (
reader = bufio.NewReader(os.Stdin)
mu sync.Mutex
)
func safeRead(p []byte) (n int, err error) {
mu.Lock()
defer mu.Unlock()
return reader.Read(p)
}方案二：每个 goroutine 独立构造 reader（推荐，零开销且语义清晰）
立即学习“go语言免费学习笔记（深入）”；
// 每个 goroutine 自行封装底层 io.Reader
go func(r io.Reader) {
br := bufio.NewReader(r) // 新实例，无共享状态
buf := make([]byte, 1024)
for {
n, err := br.Read(buf)
if err != nil {
break
}
// 处理 buf[:n]
}
}(fileOrConn)方案三：通过 channel 串行化读取（适合需顺序解析的流水线）
ch := make(chan []byte, 10)
go func() {
br := bufio.NewReader(src)
buf := make([]byte, 1024)
for {
n, err := br.Read(buf)
if err != nil {
close(ch)
return
}
ch <- append([]byte(nil), buf[:n]...)
}
}()
// 所有消费者从 ch 有序读取
for data := range ch {
process(data)
}⚠️ 注意事项：
- bufio.Scanner 同样不支持并发调用 Scan()，因其内部也依赖 *bufio.Reader 的状态；
- 不要试图通过 atomic 或 unsafe 手动“修复” bufio.Reader 的并发性——其状态耦合度高，无法安全拆解；
- 若需高性能并发读取，应优先考虑将数据源本身分片（如文件按 offset 切分），或使用无状态解析器（如 encoding/json.Decoder 配合独立 reader）。
总之，bufio.Reader 的非并发安全是明确的设计约定，而非缺陷。遵循“共享内存不如通信，通信不如独占”的 Go 并发哲学，合理分配 reader 实例或引入轻量同步，才是健壮、可维护的实践路径。
