goroutine 泄漏或滥用是性能崩塌主因，需通过 runtime.NumGoroutine() 基线对比、pprof/goroutine 和 pprof/block 分析定位阻塞点，避免 for 循环裸启 goroutine，改用带 ctx 控制的 worker pool。
大量 goroutine 不是并发提速的捷径，而是性能崩塌的第一征兆。你看到的卡顿、延迟飙升、内存暴涨，大概率不是业务逻辑慢，而是 runtime 正在被数万 goroutine 拖垮调度器和 GC。
怎么一眼识别 goroutine 是否失控
别等服务挂了才查——启动后立刻打 baseline：
- 服务刚启动时执行
runtime.NumGoroutine()，记下数值（通常是 3–6） - 压测 5 分钟后再次调用，若从 5 增到 5000+，且不回落，基本可断定泄漏或滥用
- 访问
http://localhost:6060/debug/pprof/goroutine?debug=2，重点扫三类堆栈：chan receive、netpoll、semacquire——它们卡住超过 10 秒，99% 是没接ctx.Done()或 channel 没关 - 用
go tool pprof http://localhost:6060/debug/pprof/block看阻塞热点，若chan send占比超 40%，说明生产者/消费者严重失衡
为什么 for 循环里直接 go 就会翻车
这是最典型的“并发幻觉”：以为启得越多越快，实际只是把压力从 CPU 转嫁给了内存和调度器。
- 每启动一个
goroutine，至少分配 2KB 栈空间；10000 个就是 20MB，GC 频繁 STW -
runtime.gopark在 pprof 中占比超 70%，说明 P 大量时间花在挂起/唤醒，而非干活 - 错误写法：
for _, item := range items { go process(item) }→item地址被所有 goroutine 共享，结果全处理同一个值 - 正确写法：显式传参，
go process(item)改为go func(x Item) { process(x) }(item)
用 worker pool 替代裸启 goroutine 的实操要点
固定数量的长期 worker + 缓冲 channel 是目前最稳、最易控的方案，8–32 个是黄金区间。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 缓冲 channel 大小不能拍脑袋：按峰值 QPS × 平均耗时估算，比如 200 QPS × 0.1s = 20，再 ×2 安全系数 → 设
make(chan Job, 40) - 千万别用无缓冲 channel 当任务队列，它会让上游 handler 直接阻塞，等于把背压甩给 HTTP server
- I/O 密集型（HTTP/DB）设 2×–4× CPU 核数；CPU 密集型（加解密/压缩）严格 ≈
runtime.GOMAXPROCS() - 每个 worker 必须监听
ctx.Done()：select { case job :=
goroutine 泄漏的两个隐藏元凶
它们不报错、不 panic，但会在几小时后让 runtime.NumGoroutine() 持续爬升，pprof 显示一堆卡在 http.Get 或 db.Query 的 goroutine。
-
http.Client忘关resp.Body.Close()→ 底层连接无法复用，client 内部悄悄起新 goroutine 管理连接池，越积越多 - worker 启动时用了
context.WithTimeout，但 handler 里没把该 ctx 传给http.Do或db.QueryContext→ timeout 触发不了，goroutine 永远等在 I/O 上
真正难的不是写对语法，而是每一处 go 后面都得想清楚：它什么时候停？谁通知它停？停不掉时内存和调度器替你买单。
