1. 先搞清楚goroutine 泄露到底是个什么“病”写了几年 Go我最大的感受是goroutine 轻量是真轻量但一旦用不好它带来的麻烦一点也不比线程少。很多人一听到 goroutine 泄露第一反应是“内存占用高”但实际上它的危害远不止内存。进程里的 goroutine 数量一旦失控CPU 调度开销会暴涨GC 压力会成倍增加最后整个服务响应变慢、出现超时甚至直接 OOM 把进程带走。本质上goroutine 泄露就是一些 goroutine 由于种种原因永远无法退出它们既不干活也不释放堆在那里白白吃资源。我先说个真实案例。之前我维护过一个内部 API 网关平时 goroutine 数量稳定在几百到一千左右。某天发布新版本后线上监控显示 goroutine 数像一个不会停的计数器每隔几分钟就涨几千从上午十点一直到下午直接突破了二十万。当时还没 OOM但服务已经明显卡顿接口 P99 从 50ms 涨到了 3s。后来用 pprof 抓 goroutine 栈定位到一个消息队列消费模块里面有个超时控制写错了导致每个处理中的请求都“卡死”在一个永不返回的等待上。这就是典型的协程泄露goroutine 被永久阻塞并且持有它的人已经忘了要让它退出。我写这篇文章不是想抄官方文档而是想把 goroutine 泄露这件事从头到尾讲透它到底是什么、为什么会发生、如何在代码里识别、如何用工具排查、以及最常见的几种场景怎么预防和修复。文章面向的是已经能写 Go、能跑项目的开发者但如果你刚入门也能从中建立一套完整的排查思路。先给一个最简单的类比goroutine 就像你在公司里开的工单。正常情况每个工单完成就会关闭。如果你开启工单之后处理人因为某些原因不再跟进但工单系统里还留着这个工单那就一直占着系统资源。随着时间推移没人处理的工单越来越多系统最终就瘫痪了。协程泄露就是这些“永远不关闭的工单”。要解决这个问题必须知道 goroutine 什么时候会退出。goroutine 退出的条件只有两个函数正常返回或者程序 panic 被 recover 后继续。只要函数还在运行无论它是阻塞在 channel 上、等待锁、还是休眠中goroutine 都算活着。也就是说只要你的代码里存在“永远等不到信号”的逻辑泄露就产生了。理解这一点排查方向就清晰了。2. 为什么 goroutine 比内存泄露更隐蔽内存泄露还有一个明显特征内存使用量曲线持续上升容易被人发现。但 goroutine 泄露不一样很多场景下内存并不一定立刻暴涨。因为一个“卡住”的 goroutine 可能只占很小的栈空间初始 2KB就算有几千个也才几 MB。如果没有持续产生新 goroutine系统可能看起来“很正常”直到某天流量突增一次性触发大量同类问题才会把系统压垮。我见过最坑的一次是某个 cron 任务。它每天凌晨跑一次每次启动 50 个 worker 去处理一批数据但其中 20 个 worker 会因为等待一个永远没人发送的 channel 而阻塞。任务结束后阻塞的 20 个 goroutine 还在但因为每天只创建 50 个数量增长很慢。运维看内存曲线几乎没波动直到两个月后goroutine 累积到了几千个cron 任务每跑一次系统内存就明显涨一截。查到最后问题其实是那个 channel 的发送方逻辑被注释掉了。这正好说明了我强调的要点排查 Go 程序资源问题必须把 goroutine 数量和内存放在同等重要的位置。甚至 goroutine 数量更有先导性因为它直接反映程序逻辑是否正确。一个健康的后端服务goroutine 数量应该是一个相对稳定的值或者随着请求量上下波动并且能回落到基线水平。如果 goroutine 基线上涨就说明有泄露。还有一个隐蔽点是goroutine 泄露经常和“业务不报错”共存。只要没有 panic没有超时业务代码可能一直显示成功但那部分工作其实已经丢失了。比如从 channel 读取数据接收方 goroutine 不等了发送方还在等一个接收者出现这时候发送方 goroutine 就泄露了。而发送的数据没人接收上游业务不知道还会继续发新的数据过来。这种“静默丢失”比显式报错更可怕。从调试难度来说内存泄露有 heap profile 可以精确到对象但 goroutine 泄露只能看到调用栈。调用栈告诉你这个 goroutine 等在哪里但为什么等、谁制造了这个等待条件通常需要结合业务代码一起分析。再加上有些 goroutine 是标准库内部创建的比如 HTTP 连接的读循环、写循环让你很难一眼分清哪些是“必须常驻”的哪些是“异常残留”的。这就是为什么实战中很多人抓了 pprof 也不知道下一步该干什么。3. 常见的 goroutine 泄露场景逐个拆开看我还是按实际遇到过的频率来排序把那些最容易藏泄露的场景梳理出来。每一个场景都配上典型的代码形态和修复思路你可以直接对照自己的项目检查。3.1 无缓冲 channel 的发送或接收永远等不到对方无缓冲 channel 是最经典的泄露温床。发送方在 channel 上发送数据时必须等一个接收方准备好接收方接收数据时必须等一个发送方准备好。只要这个“配对”永远不发生就会卡死。我写过一段非常典型的错误代码拆分之后大致长这样func worker() { ch : make(chan int) go func() { // 业务处理这里其实需要从 ch 拿到数据才能继续 data : -ch fmt.Println(data) }() // 这里忘记向 ch 发送数据也没有 close(ch) time.Sleep(time.Second) }这段代码执行后匿名 goroutine 在-ch处永久阻塞。因为 ch 既没有数据也没有被关闭。这个 goroutine 就泄露了。很多人写成这样是因为把 channel 当作“同步点”以为只要两个 goroutine 同时存在就行但 Go 的 channel 语义里没有发送就没有接收这两者必须成对出现。修复方式也很简单要么保证发送方一定发送要么使用带缓冲的 channel要么用 select 加超时兜底。实际项目中我推荐每个 channel 操作都考虑“如果对方不来了怎么办”。带缓冲的 channel 能降低卡死概率但缓冲满了之后同样会阻塞发送方。真正的稳妥做法是配合selectselect { case data : -ch: fmt.Println(data) case -time.After(3 * time.Second): fmt.Println(timeout, give up) }time.After会在到期后给一个 channel 发送值所以这个select最多等 3 秒就退出。虽然不会再泄露但要注意time.After本身也会创建 goroutine 和分配 timer如果放在循环里频繁调用会产生额外的开销更好的方式是用context.WithTimeout或timer复用。3.2 只创建 goroutine 却没有通知它退出的机制这种情况在“后台任务”“定时拉取”“轮询”里最常见。很多人写代码时习惯直接go func()但函数体里是无限循环也没有退出机制。这类 goroutine 不是一次性泄露而是“随创建随堆积”。看这个例子for i : 0; i 100; i { go func() { for { // 模拟做某件事 time.Sleep(1 * time.Second) } }() }这 100 个 goroutine 永远不会退出因为循环没有 break也没有 channel 信号触发返回。虽然它们不是致命的如果业务就是要长期跑 100 个轮询协程但问题是如果这 100 个 goroutine 是在某个请求处理函数内部启动的每来一个请求就启动 100 个程序就会迅速失控。判断这类泄漏的检查清单是你的 goroutine 函数体里有没有“退出条件”没有退出条件的 goroutine如果它的生命周期不等于进程生命周期就一定是潜在缺陷。正确做法在 goroutine 内部用一个 done channel 控制循环退出。done : make(chan struct{}) go func() { defer close(done) for { select { case -done: fmt.Println(stop) return default: time.Sleep(1 * time.Second) } } }()这个例子只是一个最小的清理示意。更标准的控制手段是context.Context。Go 官方也建议用 context 来传递取消信号。比如ctx, cancel : context.WithCancel(context.Background()) go func() { for { select { case -ctx.Done(): return default: } time.Sleep(1 * time.Second) } }() // 需要停止时 cancel()一旦cancel()被调用ctx.Done()就会立即返回。使用 context 的好处是它还可以传递超时、自定义值等非常适合贯穿整个请求链路的取消控制。3.3 定时器和 time.After 使用不当定时器相关泄露很少有人一开始就注意到但它坑过不少人。先看一个for { select { case -time.After(1 * time.Minute): doSomething() } }这个写法的问题是time.After每次循环都会创建一个新的定时器而且这个定时器在触发之前无法被垃圾回收。如果循环迭代非常频繁可能同时存在大量未触发的定时器它们各自关联了一个内部的 goroutine 或堆上的计时器对象。虽然这些定时器最终会触发并释放但你的循环如果每秒执行几百次堆积量就很可观了。正确的替代方案是使用time.NewTicker或time.NewTimer并且在不再使用时调用Stop()。比如一个稳定的轮询循环ticker : time.NewTicker(30 * time.Second) defer ticker.Stop() for { select { case -ticker.C: doSomething() case -ctx.Done(): return } }ticker.C是同一个 channel 对象一直复用不会重复创建定时器。这里要注意一个细节defer ticker.Stop()只会在函数退出时执行如果你的循环要长期跑Stop 最好放在循环外或配合退出逻辑使用。还有一种泄露是time.Sleep配合 channel 的误用。比如func f() { for { time.Sleep(1 * time.Second) ch - 1 } }接收方不再读取 ch而且 ch 是无缓冲的发送方就会永久阻塞在ch - 1。这本质上是 3.1 里的 channel 收发不匹配但根因是发送方的循环没有考虑接收方状态。结合 context 能更好解决问题。3.4 锁、sync.WaitGroup 误用导致的永久阻塞互斥锁和WaitGroup也是常见的“隐形杀手”。一旦某个 goroutine 在持有锁的逻辑里永久阻塞后续所有想获取同一把锁的 goroutine 都会排队卡住这种现象在日志上表现为大量 goroutine 阻塞在同一个锁的等待上。WaitGroup误用更常见Add和Wait的调用顺序不对或者Done没有被调用导致Wait永远不返回。var wg sync.WaitGroup for i : 0; i 10; i { wg.Add(1) go func() { // 如果这里 panic且没有 recover // 那 wg.Done() 永远不会执行 defer wg.Done() doSomething() }() } wg.Wait()如果doSomething()发生 panic而 panic 未被 recover进程会崩溃但如果 panic 被外层 recover 了defer wg.Done()其实会执行因为 defer 在栈展开时依然生效。真正的坑是有些人把wg.Done()写在业务逻辑之后没有用defer一旦中途 return、panicDone 就不会执行。所以我的习惯是wg.Done()务必紧跟 goroutine 开头且必须用 defer。锁的问题更多出在“自己锁自己”或者“锁的释放逻辑在对方的 goroutine 里”。最佳修复方式不是乱改锁而是重构代码把锁的持有时间降到最小并且避免在持锁期间做任何 IO 或阻塞操作。如果把持锁期间读文件、请求 API一旦网络不通这个锁就成全区阻塞的源头。3.5 HTTP 客户端连接池里的协程残留Go 标准库的 HTTP 客户端本身会管理连接池正常情况下连接池的 goroutine 是安全的。但如果你使用http.Client时设置不当可能出现一些隐藏的 goroutine 卡住。比如Response.Body没有关闭那个连接就不会归还给连接池读循环可能一直停在等待服务端数据的阶段。每发一次请求就泄漏一个连接相关的 goroutine跑一段时间后连接池耗尽服务出现大量connection reset。修复很简单始终关闭 Response.Body而且要尽早关闭最好在读完数据后的第一条语句就开始处理。resp, err : http.Get(https://example.com) if err ! nil { return err } defer resp.Body.Close() body, err : io.ReadAll(resp.Body)但这里有个细微的问题defer是在函数退出时才执行。如果函数后面还有耗时操作响应体一直没读完连接会一直占着。所以更严格的做法是在读完数据后立刻主动 Closebody, err : io.ReadAll(resp.Body) resp.Body.Close()另外http.Client的Timeout字段不能只设了Transport而忘了整体超时。我认为一个健康的 HTTP 客户端配置应该同时具备DialContext超时建立连接超时TLSHandshakeTimeoutTLS 握手超时ResponseHeaderTimeout等待响应头超时Timeout整个请求时长上限这些参数可以避免因对端一直不发数据而永久等待。写不好的场景在长连接服务中特别常见一些内部 RPC 调用根本没设 timeout对端一个 bug 挂了这边所有 goroutine 都在等待整个应用被拖垮。3.6 context 该 cancel 没 cancel这个场景太常见了尤其在 web 服务里。从请求进入 handler 开始你就应该基于r.Context()创建一个可传播的 context。但如果你自己用context.Background()代替然后启动了多个子 goroutine请求结束后没人通知它们它们就可能一直运行。比如func handler(w http.ResponseWriter, r *http.Request) { go func() { // 做某个耗时操作 time.Sleep(10 * time.Second) fmt.Println(done) }() w.Write([]byte(ok)) }每次请求都会启动一个 10 秒后才结束的 goroutine。如果请求量很大同时有上万个 goroutine 在 sleep它们不会立刻退出只是白白占着栈空间。修复思路是使用context.WithTimeout(r.Context(), 2*time.Second)并监听ctx.Done()请求超时后 goroutine 能感知并退出。这类问题不是“立刻崩溃”但迟早会压垮系统。4. 检测和定位从 runtime 数值到 pprof 实战先别急着改代码检测和定位是排查泄露的核心环节。Go 给开发者提供了非常有用的工具链只要会用就能一步步缩小范围。4.1 用 runtime.NumGoroutine 做初步观测最粗暴但最直观的方法是在关键节点打印当前 goroutine 数量。对于 HTTP 服务可以在中间件里记录开始和结束时的 goroutine 数量再对比差值对于后台任务可以在每次任务执行前后记录。我自己习惯在日志里加上这个信息配合 Prometheus 做一个 goroutine 数量的指标监控http.HandleFunc(/debug/goroutine, func(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, goroutine count: %d\n, runtime.NumGoroutine()) })如果你看到 goroutine 数量在流量平稳的情况下持续增长、不会回落到基线基本可以确定存在泄露。但只能判断“有没有”还不能定位“在哪”。4.2 pprof定位泄露的黄金工具net/http/pprof是 Go 标准库内置的性能分析工具。对正在运行的 HTTP 服务在代码里引入import _ net/http/pprof并在某个端口开启 HTTP 服务也可以复用业务服务端口然后访问http://localhost:6060/debug/pprof/就能看到各项性能指标。重点看goroutine这一项。抓取当前所有 goroutine 的堆栈信息最常用的是go tool pprof http://localhost:6060/debug/pprof/goroutine进入 pprof 交互式命令行后输入top它会列出当前 goroutine 数量最多的函数调用栈。比如你看到大量 goroutine 阻塞在sync.runtime_SemacquireMutex说明这些 goroutine 在等待锁阻塞在chan receive说明它们在等待 channel。更直观的方式是使用go tool pprof -seconds30 http://localhost:6060/debug/pprof/goroutine这个命令会采样 30 秒内的 goroutine 状态生成一份 profile 文件然后进入交互界面。输入web可以生成调用图如果是 Linux 且安装了 graphviz就能看到每个函数上挂了多少个 goroutine。如果没有图形环境用list 函数名看对应源码行号也行。注意有一个关键技巧抓 goroutine profile 的时机。泄露分两种匀速增长型和突发型。如果是匀速增长随便抓一个瞬间就能看到大量同类调用栈。如果是突发型要在流量高峰或系统卡顿的窗口内抓取否则数量不明显。我更推荐对比“连续两次抓取”。间隔 10 秒分别抓两份 profile用diff方式看新增的 goroutine 是从哪个函数启动的。pprof 交互界面里可以用top配合goroutine的起始函数和当前阻塞位置能非常清晰地定位。4.3 如何快速区分“合法常驻”和“异常残留”刚接触 pprof 时你可能会被大量 goroutine 吓到因为标准库内部也有很多 goroutine 是被程序正常使用的。比如runtime.gopark、runtime.netpoll、signal_recv等这些是系统运行时自带的此外每个 TCP 连接可能有读/写两个 goroutine 在等待。判断原则很简单看它等在哪里以及谁创建的。如果是net/http.(*conn).reader、net/http.(*conn).writer这些一般是活跃连接如果是你自己业务里的main.handleRequest.func1且阻塞在某个 channel 接收上这就是嫌疑最大的点。还可以看 goroutine 栈里的创建时间和调用来源。我碰到过最迷惑的 pprof 输出是grpc.(*ClientStream).RecvMsg阻塞了一堆 goroutine。很多人以为是 gRPC 客户端泄露其实是因为服务端没有返回响应且客户端的RecvMsg没有设超时。这种问题必须结合对端状态一起排查不能只怪客户端。4.4 为线上服务临时增加的排查手段如果服务进程已经跑乱了pprof 端口没开或者不方便开你还可以通过发送 SIGQUIT 信号来触发 Go 运行时打印所有 goroutine 的栈信息。这个方式对 Linux 服务尤其好用kill -QUIT pid执行后进程不会崩溃而是在 stderr 或日志中输出一份完整的 goroutine stack dump。这个 dump 信息非常全每一条 goroutine 的状态、阻塞位置、创建位置都有。虽然会打断服务一小段时间但作为紧急诊断手段非常有效。注意别随手在生产环境做最好在预发环境模拟。还有一种方式是使用go.uber.org/goleak这个库。它主要用于测试里检测是否发生了 goroutine 泄露。只需在测试末尾调用goleak.VerifyNone(t)如果测试过程中启动的 goroutine 没有正常退出测试就会失败。这个工具我在写公共库时一定会加上用来保证自己暴露出去的函数不会偷偷泄漏 goroutine。5. 修复套路从结构上消除泄露知道了“哪里泄露”之后修复时不要只打补丁。拿 3.2 里的轮询 goroutine 来说如果只是在代码中指一两个关闭信号以后还可能犯同样的错误。我建议从结构层面入手建立一套统一的 goroutine 管理方式。5.1 所有 goroutine 都必须有退出路径从今天起你可以在代码 review 时给自己定一个硬性规则凡是go关键字启动的函数函数体内必须能找到channel、context.Done()、sync.WaitGroup、超时等退出机制中的至少一种。如果找不到这个 goroutine 就属于不安全的得改。这个规则在绝大多数 Go 项目里都适用。比如启动一个一次性执行的任务则任务本身必须调用donechannel 或返回。启动一个常驻后台任务则必须有cancel或done来让它退出。启动一个 HTTP 请求调用则必须有超时控制和 Body 关闭。在代码里你会经常看到像go func(){ defer wg.Done(); ... }()这种写法。这里的defer wg.Done()就是一个退出路径只是它不是主动退出而是任务结束后的收尾。所以严格来说“退出路径”还包括任务终点的必然执行。这个保证了即使业务代码出现意外Done()依然能执行Wait不会一直阻塞。5.2 使用 errgroup 管理并发任务的取消对于一组并行的 goroutine最优雅的工具是golang.org/x/sync/errgroup。它可以让你像写普通代码一样管理多个 goroutine 的生命周期并且只要其中一个任务返回错误它就会自动 cancel 其他的任务前提是你正确使用了 context。举个例子g, ctx : errgroup.WithContext(context.Background()) for _, task : range tasks { task : task g.Go(func() error { return process(ctx, task) }) } if err : g.Wait(); err ! nil { // 处理错误 }errgroup.WithContext会创建一个新的 context。任何一个g.Go返回非 nil error 时errgroup 会调用 cancel让其他 goroutine 通过ctx.Done()感知并退出。这个机制直接把“并发”和“取消”绑定在一起比手动管理一堆 channel 轻量得多。不过 errgroup 有个局限它一次只能捕获第一个错误后续的错误会被丢弃。如果你需要收集所有错误就得自己封装。另外g.Go内部的一个坑是如果任务本身 panicerrgroup 内部的 goroutine 会崩溃进程照样崩溃所以 panic 还是要自己 recover。不能因为有 errgroup 就忽略 goroutine 里的异常处理。5.3 控制并发上限信号量semaphore思想很多 goroutine 泄露的根源不是“停不下来”而是“一下子太多”。一次请求开启 100 个 goroutine每个 goroutine 又去请求下游下游慢了这 100 个 goroutine 全部卡住。代码上看似每个 goroutine 都有超时和退出但总量已经超出了系统承受范围结果还是表现为数量堆积、系统崩溃。这时候需要用信号量限制并发。Go 的 buffered channel 就能实现信号量sem : make(chan struct{}, 10) for _, task : range tasks { sem - struct{}{} go func(t Task) { defer func() { -sem }() process(t) }(task) } // 等待全部完成 for i : 0; i cap(sem); i { sem - struct{}{} }这个写法里sem的容量就是最大并发数。第 11 个任务要在sem - struct{}{}处等待直到有 worker 回收 slot。如果每个 worker 都有正确的退出逻辑信号量机制能防止“风暴式”启动 goroutine。但要注意上面的等待完成方式写得比较绕。更常见的写法是用sync.WaitGroup配合信号量var wg sync.WaitGroup sem : make(chan struct{}, 10) for _, task : range tasks { wg.Add(1) go func(t Task) { defer wg.Done() sem - struct{}{} // 获取令牌 defer func() { -sem }() // 释放令牌 process(t) }(task) } wg.Wait()这个模式在实际项目里非常稳定。但它有一个细节wg.Add必须在启动 goroutine 之前调用尤其是在循环里千万不要在 goroutine 内部再wg.Add否则可能出现Wait已经结束但后面又有任务加入的情况引发 panic。5.4 避免手动管理生命周期混乱的 channel对于复杂的并发协作场景我强烈建议优先使用context.Context和errgroup而不是自己造一套 channel 信号。自己造的信号 channel 很容易出现“发送方忘记关闭”“接收方重复关闭”等错误。一个常见崩溃就是close(done) // 某次被重复调用了重复关闭 channel 会导致 panic而且是运行时 panic非常难追查。更好的做法是保证“只有一个发送者并且只关闭一次”如果做不到就考虑使用sync.Once来包裹 close。var once sync.Once stop : func() { once.Do(func() { close(done) }) }这个模式让我少踩了很多坑。凡是多个 goroutine 都可能触发“停止”逻辑的场景我都无脑套sync.Once。6. 实战排查流程从发现问题到修复我都是怎么做啰嗦了这么多我把实际排查一个 goroutine 泄露的完整流程写出来大家可以照着走。这个流程适用于线上服务、后台任务、工具脚本。6.1 第一步确认是否存在泄露观察runtime.NumGoroutine()的变化曲线。如果是 HTTP 服务可以直接在监控系统里把 goroutine 数和请求 QPS 画在一张图上。如果 QPS 回到零但 goroutine 数量不下来说明有常驻 goroutine 没退出。这一步最重要因为它直接决定了后续方向。没有确认泄露就盲目去看 pprof容易被正常的常驻协程干扰。6.2 第二步抓取两份 goroutine dump 做对比先抓一份curl http://localhost:6060/debug/pprof/goroutine?debug1 -o goroutine1.txt等待 30 秒左右再抓一份curl http://localhost:6060/debug/pprof/goroutine?debug1 -o goroutine2.txt用diff goroutine1.txt goroutine2.txt看新增的 goroutine 集中在哪些函数。普通视角下不需要看全部只看新增行和重复行里的函数名。如果增长的 goroutine 栈顶都停在某个 channel 接收操作或某个 select 语句那么这个函数就是泄露点。比如栈顶是main.watcher.func1 goroutine channel receive main.queueConsumer那就去main.queueConsumer里找 channel 的发送方在哪。6.3 第三步用源码定位发送/接收路径确认泄露点后回到代码里看这个 channel 的创建和所有引用位置。常见问题接收方和发送方不在同一个生命周期控制范围内比如接收方是主流程创建的 goroutine发送方却是某个子流程临时创建的子流程出错后就没有人发数据了。这类“不对称”问题靠猜很难但只要把 channel 的所有引用点画一张脑图就一目了然。如果泄露点是锁等待就去看到底是谁持锁没释放。通常是持锁代码里调用了阻塞操作。修复方式要么去掉阻塞调用要么在持锁期间不等待任何外部资源。6.4 第四步写压测脚本复现并验证修复完不能只靠眼睛看。我会用一个高并发压测脚本模拟之前的场景。比如原先 QPS 100我压到 200 并持续跑 10 分钟然后观察 goroutine 数量是否稳定。压测脚本可以很简单用go-wrk或者自己写一个小程序发请求。关键是看修复前后的 goroutine 增长曲线差异。如果修复后 goroutine 数量依然不下降就说明还有第二个泄露点。继续重复第二步到第四步。6.5 第五步为公共代码加 goleak 测试如果你的代码是公共库或者公司内部多个服务依赖的组件那么每次改动并发相关逻辑都要跑goleak测试。我自己的经验是一个库函数只要暴露了 goroutine 启动能力就必须在测试文件里加上func TestSomething(t *testing.T) { defer goleak.VerifyNone(t) // 测试逻辑 }这样能非常快地发现某个版本引入的 goroutine 泄露。虽然 goleak 在有些标准库场景下会误报比如测试环境里的某些网络连接但绝大多数业务场景都适用。7. 常见问题速查表与避坑经验这里整理一份我在实战中反复遇到的典型问题以及对应的排查方向和解决建议。症状典型 goroutine 栈常见根因修复方向goroutine 数量持续增长请求结束后不下降channel receive或select无缓冲 channel 收发不匹配检查发送方是否在所有路径上都会发送或 closegoroutine 大多阻塞在sync.Mutex.Locksync.runtime_SemacquireMutex某个 goroutine 持锁后永久阻塞缩小锁范围持锁期间不做 IO/阻塞操作WaitGroup相关 goroutine 不返回sync.(*WaitGroup).Waitwg.Done()未被执行在 goroutine 开头使用defer wg.Done()大量 goroutine 阻塞在time.After的等待time.Sleep或time.NewTimer定时器没有停止使用Ticker或Timer.Stop()大量 HTTP 相关 goroutine 残留net/http.(*persistConn).readLoopResponse.Body没有关闭或连接池耗尽确保 Body 关闭设置 Transport 的 MaxIdleConns使用 context 仍有 goroutine 残留context.Context.Done未触发没有调用cancel在请求入口使用defer cancel()goroutine 数量稳定但内存持续上涨无明显阻塞goroutine 都在干活业务逻辑里有内存持有问题结合 heap profile 一起排查多个 goroutine 卡在同一个chan sendchannel send接收方被关闭或者退出但发送方还在发加入接收方是否存活的判断或使用select检测 done再补充几个避坑经验第一不要在 recover 里吞掉所有异常而不记录。很多人写 goroutine 都会加defer recover()但 recover 之后既不打印也不上报。这会导致 goroutine 内部死循环继续跑、数据丢失而系统中没有任何线索。至少要在 recover 里打日志或者发送错误监控。如果希望优雅退出可以在一段内部设置标志位让外层也能感知。第二channel 关闭的“发送方原则”不要破坏。Go 官方文档明确说channel 只能由发送方关闭。如果你在接收方关闭 channel发送方再往里面发送就会出现 panic。这个 panic 还是在写 goroutine 中抛出的可能导致写 goroutine 崩溃退出。很多人以为 channel 泄露就是内存问题其实还有 panic 问题。用sync.Once关闭 channel 能避免重复关闭的 panic。第三别让 goroutine 数量成为业务幂等的替代品。有的系统处理超时后直接把 goroutine 丢弃或假装任务还在进行这会让业务数据状态与实际处理不一致。真正健康的设计是每个任务都有一个可取消的 context取消之后任务能在下一个检查点退出并标记为失败而不是永远消失。比如消费者从队列取任务任务处理超时了正确做法是把任务放回队列或者记录失败而不是让它一直“处理中”。第四理解 goroutine 栈大小不是写满才释放。goroutine 初始栈很小会根据需要动态增长最大可到 1GB。如果某个 goroutine 里用了很大的局部变量或者递归调用很深栈会不断增长。当 goroutine 阻塞时即使不运行栈空间也不会立刻还给系统。所以有时候 goroutine 数量不多但内存已经很高就是某些 goroutine 栈很大。排查这种问题除了看数量还要看每个 goroutine 的栈大小pprof 里可以看到栈的长度信息。8. 最后的实战心得聊了这么多其实 goroutine 泄露不像别的 bug 那样“有 Bug 就会崩”它更像一种慢性病。程序可能还好好的但资源水位越来越高最后在某次流量波动里突然垮掉。而解决它不只是找到某一行代码的问题而是要建立起对并发生命周期的意识。我个人现在写 Go 代码有一个近乎固执的习惯任何go func()启动后第一件事就是考虑它的退出机制。这个机制可以是defer wg.Done()可以是ctx.Done()可以是 channel 的 close甚至可以是time.After加 select。反正不能“裸奔”。哪怕只是一个清理临时文件的 goroutine我也要让它能被外部信号终止否则测试和运维都会很难办。另一个经验是监控 goroutine 数量比监控内存更敏感。很多内存问题最终体现在 goroutine 数量上因为 goroutine 本身持有栈、持有资源、持有引用。线上环境我会用 Prometheus 每 15 秒采集一次runtime.NumGoroutine()和 goroutine 栈总数。只要发现数量曲线趋势性上扬就立刻拉 pprof 看。等到 OOM 再排查往往就只能从 core dump 里猜了。如果你真想系统化提升这块能力日常写代码时可以刻意做一些练习比如实现一个小型的 worker pool要求所有 worker 都能响应取消信号或者写一个带超时的 channel 消息转发器确保任何消息在超时后都能被丢弃。这些练习做完再回头看自己的历史代码会发现很多能优化的地方。最后分享一个排查时让我印象深刻的细节有次我查泄露pprof 显示几百个 goroutine 等都停在一个time.Sleep上但代码里根本没有这么长时间 sleep。后来发现是某个第三方库的Sleep包了一层跨进程休眠依赖导致调用栈被截断。所以看不出来的时候也要怀疑“栈顶的函数”可能是被包装过的往上翻栈中间的帧才是业务代码。goroutine 泄露没有银弹但只要掌握好退出路径、context 传递、channel 配对、工具链这几板斧大部分问题都能在五分钟内定位。希望这篇内容对你有实实在在的帮助。