协程泄漏在kubernetes中是代码、生命周期管理与调度边界三重失配所致；典型表现为pprof显示大量chan receive状态，主因是close太晚、context未透传或errgroup未等待，修复需确保range通道配套关闭、所有goroutine接收ctx.done()信号，并用信号量控制fan-out并发。
协程泄漏在 Kubernetes 环境中不是单纯的 Go 代码问题，而是“代码 + 生命周期管理 + 调度边界”三重失配的结果。单纯看 runtime.NumGoroutine() 持续上涨，大概率是服务已脱离容器生命周期控制——比如进程未响应 SIGTERM、context 未透传到 goroutine 内部、或 channel 关闭时机与 Pod 终止不一致。
pprof/goroutine?debug=1 显示大量 chan receive 状态
这是最典型的通道阻塞泄漏信号。Kubernetes 中的常见诱因不是“没写 close”，而是“close 太晚”或“close 不由 owner 执行”。
- Pod 收到 SIGTERM 后，主 goroutine 可能已退出，但后台 worker 仍在
for v := range ch中等待——因为ch未被关闭，且 sender 已随主流程退出 - 使用
errgroup.Group时，若未调用eg.Wait()就直接 return，group 内部的 context.Cancel() 不会被触发，所有子 goroutine 无法收到ctx.Done() - HTTP handler 启动 goroutine 但未将 request.Context() 透传进去，导致超时或取消信号完全失效
修复关键：所有 range ch 必须配套明确的关闭方；所有 goroutine 启动必须带 ctx 参数，并在 select 中监听 ctx.Done()。
goroutine 数量随请求量线性增长，且不回落
说明并发控制缺失，常见于未限流的 Fan-Out 场景，比如一个 HTTP 请求 spawn 出 N 个 goroutine 去调用下游，N 随请求并发数放大。
- 错误模式：
for _, item := range items { go process(item) }—— 没有并发数限制，压测时瞬间拉起数千 goroutine - 正确做法：用带缓冲的 channel 当信号量，或用
semaphore.NewWeighted(int64(n))（来自golang.org/x/sync/semaphore） - Kubernetes 特别注意：HPA 扩容后，新 Pod 的 goroutine 池若未做初始化隔离（如复用全局 channel），会导致跨 Pod 的资源争用
验证方式：在 init() 或 main() 中打印 runtime.GOMAXPROCS(0) 和 runtime.NumCPU()，确认是否被容器 resources.limits.cpu 错误压制，导致调度器被迫创建更多 goroutine 补偿。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
Pod 重启后 goroutine 数仍缓慢爬升
这往往指向“资源未清理”的隐性泄漏，比如定时器、net.Conn、http.Client.Transport 连接池，它们本身不显式启动 goroutine，但内部会 spawn background worker。
-
time.Ticker忘记调用t.Stop()：每个 ticker 启动一个 goroutine 持续发送时间事件 -
http.Client未设置Timeout或Transport.IdleConnTimeout：空闲连接保活 goroutine 积累 - 第三方 SDK（如 Kafka consumer、Redis client）未调用
Close()：内部监控/心跳 goroutine 持续运行
排查重点：不要只看自己写的 go func()，用 go tool pprof -http=:8080 <binary><profile></profile></binary> 查看 goroutine 堆栈，过滤出非业务路径的调用，比如 net/http.(*persistConn).readLoop 或 github.com/segmentio/kafka-go.(*Conn).background。
如何让泄漏在上线前暴露
生产环境的泄漏往往需要数小时甚至数天才显现，但可通过三项低成本手段提前拦截：
- 在 CI 阶段加一条检查：启动服务后 sleep 5s，执行
curl -s http://localhost:6060/debug/pprof/goroutine?debug=2 | grep -c 'created by'，对比基线值，波动超 20% 则失败 - 所有对外 HTTP 调用必须包装
context.WithTimeout(ctx, 5*time.Second)，禁止裸用context.Background() - 在 main 函数末尾加
defer func() { fmt.Printf("goroutines left: %d\n", runtime.NumGoroutine()) }()，确保进程退出前 goroutine 归零
最易被忽略的一点：Kubernetes 的 preStop hook 执行时间默认只有 30 秒（受 terminationGracePeriodSeconds 限制），如果 cleanup 逻辑耗时更长，会被强制 kill——此时 goroutine 清理根本没机会执行。
