go批处理性能瓶颈通常源于并发模型误用、内存分配碎片化和i/o阻塞未解耦；应检查gomaxprocs设置、避免循环中创建waitgroup/chan，采用带缓冲chan的worker pool限流复用goroutine，批量i/o合并操作，预分配内存并禁用高频逃逸。
Go 程序做批处理时性能上不去，通常不是因为语言本身慢，而是并发模型没用对、内存分配太碎、I/O 阻塞没解耦——先看 runtime.GOMAXPROCS 是否被设成 1，再检查是否在循环里反复创建 sync.WaitGroup 或 chan。
用 worker pool 控制 goroutine 数量，别无脑起 10000 个
批处理常见误区是为每个任务启一个 goroutine，结果调度开销压垮系统，还可能触发 GC 频繁停顿。worker pool 能复用 goroutine、限流、避免资源耗尽。
-
runtime.GOMAXPROCS默认已设为 CPU 核数，无需手动调；重点是 worker 数量——一般设为runtime.NumCPU() * 2到50之间，具体看任务是 CPU 密集还是 I/O 密集 - 用
chan做任务队列时，务必带缓冲（如make(chan Task, 1000)），否则生产者会阻塞在发送端 - 别在每个 worker 里 new 一堆结构体；提前分配好切片、复用
bytes.Buffer或自定义对象池（sync.Pool）
批量 I/O 操作要合并，别单条提交
数据库写入、HTTP 请求、文件追加等操作，单条发起的开销远大于批量。Go 的标准库和主流驱动都支持批量接口，但默认不启用。
- 用
database/sql批量插入时，优先走INSERT INTO ... VALUES (...), (...), (...)拼接，而不是多次Exec；PostgreSQL 可用pgx.Batch，MySQL 可用mysql.InsertMany（需驱动支持） - HTTP 客户端批量请求：别用
http.DefaultClient直接串行发；改用golang.org/x/sync/errgroup并发控制 + 复用http.Transport（尤其注意MaxIdleConnsPerHost和IdleConnTimeout） - 日志或文件写入：用
bufio.NewWriterSize(w, 64*1024)包一层，避免每次WriteString都 syscall
避免在批处理循环中触发 GC 或逃逸
高频小对象分配是 Go 批处理性能杀手。编译器逃逸分析（go build -gcflags="-m"）能帮你定位问题。
立即学习“go语言免费学习笔记（深入）”；
- 循环内别用
fmt.Sprintf拼接字符串；改用strings.Builder或预分配[]byte+strconv.Append* - 结构体字段别用
*string/*int存简单值；指针会强制堆分配，且增加 GC 扫描压力 - 切片扩容要预估：用
make([]T, 0, estimatedCap)初始化，而不是append从空切片开始累积 - 如果批大小固定（如每次 1000 条），考虑用数组（
[1000]Item）替代切片，彻底避免动态分配
真正卡住性能的，往往不是算法复杂度，而是 net/http.Transport 连接复用没开、sync.Pool 对象没预热、或者日志里混着 fmt.Printf 这种同步输出——这些细节在压测时才会暴露，光看代码逻辑很难发现。
