Go worker pool 有界 channel 满载后 pprof goroutine 单调上涨，怎么定位是背压还是泄漏？

背景 我在做一个 Go 1.22 的 MQ 消费者服务（Kafka → 业务处理 → 写 MySQL），单副本 8C16G，峰值 ~2k msg/s。架构是典型的 worker pool：dispatcher 从 Kafka 拉到消息后 select { case jobs <- msg: default: dropOrRetry() }，jobs 是 make(chan *Msg, 4096)；256 个 worker for msg := range jobs 取任务处理。下游 MySQL 8.0，单实例，高峰期 P99 写延迟从 12ms 飙到 800ms+。

现象

1. MySQL 慢查询高峰期，服务 goroutine 数从基线 ~300 单调爬到 1500+，持续 20 分钟不回落，哪怕 MySQL 恢复正常后仍维持 1200 左右。
2. RSS 从 1.2G 涨到 2.6G，heap profile 里 *Msg 对象数明显上涨，但对象大小很小（~200B），不像是主因。
3. pprof 的 goroutine profile 里能看到一大片阻塞在 chan receive（runtime.chanrecv），栈顶是 worker 的 for msg := range jobs 那一行——按理说 worker 阻塞在 channel receive 是正常 idle，为什么数量会涨？
4. 关键怀疑点：dispatcher 的 select default 分支我写成了「打日志 + 走 Kafka seek 回退」，这个回退路径里我调了 client.CommitSync，怀疑这里在慢查询期间被阻塞，导致 dispatcher 协程本身堆积。

已尝试的排查

• go tool pprof -top http://.../debug/pprof/goroutine：确认了 chan receive 阻塞的大头，但分不清「新 worker 起来后还没拿到任务」vs「旧 worker 卡在下游」。
• 打了 worker 的 in-flight 计数（atomic 加减），发现高峰期 in-flight 长期维持在 250 左右，没有继续涨——这条线我暂时排除了。
• GODEBUG=gctrace=1 看 GC：频率没有异常，不是内存压力导致的 goroutine 堆积。
• 没做：把 worker 的 range loop 改成带 context.WithTimeout 的 select，看是不是下游慢查询把 worker 卡住了（这个改动还没上线，想先听下意见）。

期望得到的答案形态

1. 一个可复现的定位套路：给我一个具体的排查 checklist（命令 + 看哪个 pprof 视图 + 怎么区分「正常 idle worker」和「真泄漏 worker」），最好带 go tool pprof 的具体命令（比如 -text -top20 或 peek 怎么用）。
2. 对 dispatcher select default 里做 CommitSync 这种「回退路径阻塞」的写法，你们生产上是怎么处理的？有没有推荐的背压模式（比如：token bucket 限流 dispatcher 拉取速度 / 把回退异步化 / 用 semaphore 而不是 channel）？
3. 如果让我上 context.WithTimeout，worker 里 for msg := range jobs 和 select { case msg := <-jobs: case <-ctx.Done(): } 这两种写法在 goroutine 回收上有差别吗？range 在 channel 关闭前是不是不会主动退出？

谢谢，越具体越好，最好能给一段最小可跑的 demo 代码。