大量 goroutine 不会自动提升性能，反而因栈内存、调度开销和 GC 压力导致性能下降；应使用固定大小的 worker pool（8–32 个）配合缓冲 channel 分发任务，并依 CPU/I/O 密集型调整数量，同时用 context 防泄漏。
大量 goroutine 不会自动变快，反而常是性能下降的起点。 Go 的调度器虽高效，但每个 goroutine 仍需栈内存、调度元数据和 GC 扫描开销；当数量失控（如每请求启 100 个），瓶颈立刻从 CPU 转向内存分配、GC 停顿和调度器争抢——你看到的“卡顿”，大概率不是代码慢，而是 runtime 在拼命回收和切换。
用 worker pool 代替每任务一 goroutine
常见错误：处理 5000 条日志、调用 5000 次外部 API 时，直接 go process(item) 启 5000 个 goroutine。结果是瞬间堆内存暴涨、GC 频繁触发、runtime.NumGoroutine() 达数万，而实际并发收益趋近于零。
- 实操建议：固定启动 8–32 个长期运行的 worker，通过
chan Job分发任务（缓冲大小设为 1024 或按压测调整） - 场景适配：CPU 密集型任务（如解密、压缩）worker 数 ≈
runtime.GOMAXPROCS()；I/O 密集型（HTTP 请求、DB 查询）可设为 2×–4× CPU 核数 - 避免陷阱：别用无缓冲 channel 当任务队列——它会让 sender 阻塞，等于把背压转移到上游，可能拖垮整个请求链路
用 context 控制生命周期，防 goroutine 泄漏
泄漏现象：服务运行几小时后 runtime.NumGoroutine() 持续上涨，pprof 显示大量 goroutine 卡在 select { case 或 http.Get 上——说明它们没收到退出信号，永远等下去。
- 实操建议：所有长期 goroutine 必须接收
ctx context.Context，并在select中监听ctx.Done()；HTTP 客户端、数据库查询等 I/O 操作必须传入该 ctx - 关键细节：不要在循环里直接闭包捕获循环变量（如
for _, u := range users { go func() { db.Query(u.ID) }() }），应显式传参：go func(user User) { ... }(u) - 验证方式：开发期加日志
log.Printf("active goroutines: %d", runtime.NumGoroutine())，或用go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查看阻塞点
慎用 GOMAXPROCS，别把它当“并发加速键”
误解最深的一点：以为调高 GOMAXPROCS 就能“多开线程跑得更快”。实际上它只控制 P（逻辑处理器）数量，默认等于 CPU 核数；设太高会导致 P 间任务窃取开销上升、M 频繁切换，反而降低吞吐。
立即学习“go语言免费学习笔记（深入）”；
- 实操建议：启动时一次设置即可，如
runtime.GOMAXPROCS(12)；生产环境根据压测调整，I/O 密集型服务可试2×CPU，CPU 密集型保持默认或略低 - 性能影响：设为 1 时所有 goroutine 串行执行（适合调试）；设为 100 且机器只有 8 核，会显著增加调度锁竞争，
go tool trace可见大量 “Proc Status” 切换 - 容易踩坑：运行时频繁调用
runtime.GOMAXPROCS(n)—— 这会触发全局 stop-the-world，导致短时响应毛刺
真正难的不是写并发，而是判断“哪里不该并发”。一个 time.Now().UnixNano() 调用不值得开 goroutine，一次批量插入 100 行 SQL 用 worker pool 复用连接比开 100 个 goroutine 更稳。性能优化的终点，往往是删掉 90% 的 goroutine，留下那 10% 真正需要并行的。
