Go批量处理性能瓶颈主因是I/O阻塞、协程滥用和内存分配；应使用sync.Pool复用高频小对象（如[]byte、json.Decoder），避免GC压力，注意重置状态并检查nil；文本解析优先bufio.NewReader+定长切片，预分配结构化切片。
Go 程序批量处理性能瓶颈，90% 出现在 I/O 阻塞、协程滥用和内存分配上，而不是算法本身。
用 sync.Pool 复用高频小对象，避免 GC 压力
批量处理中频繁创建 []byte、json.Decoder、bufio.Reader 等对象，会显著抬高 GC 频率。Go 1.13+ 的 sync.Pool 是最直接的缓解手段。
- 不要复用含内部状态的对象（如已调用过
Read()的bufio.Reader），需在Put前重置缓冲区或字段 - 池中对象生命周期由 GC 控制，不能依赖
Get一定返回非 nil；始终做空值检查 - 示例：解析 JSON 流时复用
json.Decoder，但每次UseNumber()和DisallowUnknownFields()需重新设置
批量读写优先走 bufio + 定长切片，别用 fmt.Scanf 或逐行 Scanner
处理 CSV、日志、TSV 等文本批量数据时，bufio.Scanner 默认 64KB 缓冲且不可控，fmt.Sscanf 解析开销大，二者都会成为吞吐瓶颈。
- 用
bufio.NewReader+ReadSlice('\n')或ReadBytes('\n')手动控制缓冲，配合bytes.FieldsFunc或strings.SplitN切分 - 对结构化数据（如固定列 CSV），预分配
[]string切片并复用，避免每次make([]string, N) - 写入文件时，用
bufio.NewWriterSize(f, 1 设置 1MB 缓冲，再批量WriteString，比逐行fmt.Fprintln快 3–5 倍
并发控制别无脑开 go，用 worker pool 限流 + channel 流控
常见错误是 for 循环里直接 go process(item)，导致协程数爆炸、内存溢出或下游服务被打挂。真实场景需要可预测的并发度与背压。
