Go语言开发中，协程泄露就像程序里的隐形炸弹——平时看不见，爆发时直接让服务崩溃。上周我们团队就踩了这个坑，一个未关闭的channel导致线上服务内存飙升到90%，紧急回滚才避免事故。
### 协程泄露到底有多可怕？
想象你开了一家网红奶茶店，顾客（协程）源源不断进来，但后门被锁死了。很快店里挤满人，最终连站的地方都没有——这就是协程泄露的典型场景。最常见的有三种情况：
1. **channel变成黑洞**：忘记close的channel会让等待的协程永远挂起
2. **死锁修罗场**：两个协程互相等对方放锁，结果一起卡死
3. **无限循环陷阱**：比如没有设置超时的for循环，协程永远无法退出
### 用pprof当CT扫描仪
凌晨3点定位问题时，`go tool pprof http://localhost:6060/debug/pprof/goroutine` 成了我们的救命稻草。这个命令会生成像犯罪现场调查报告一样的堆栈信息，特别要盯着那些显示`blocked`状态的协程。有个神技巧：对比正常时和泄露时的火焰图，差异部分往往就是泄露源。
### 防泄露必备三件套
1. **给协程装刹车系统**：所有协程必须带`context.WithTimeout`，就像给工人配紧急停止按钮
2. **代码审查重点项**：我们团队现在强制要求每个`go`关键字都要配套生命周期说明注释
3. **压力测试模拟器**：用`-race`参数跑单元测试时，故意制造比双十一高10倍的并发量
最近GitHub有个开源项目`goroutine-leak-detector`很有意思，它能像金属探测器一样在CI阶段就发现潜在泄露。毕竟在Go的世界里，管好协程就像管好熊孩子——既要给自由，又得划清界限。
