加 buffer 不是修 bug：Go channel 阻塞排查实战

Thu, 21 May 2026 18:30:00 +0800

goroutine 数量从 200 慢慢涨到 2 万。

监控图上那条线，不陡，但一直在爬。就像水龙头没拧紧——不喷，但也不会停。

你的第一反应是什么？

加大 buffer。

make(chan int, 100) 改成 make(chan int, 1000)。重启。观察。好像好了。

三天后，又涨回来了。

这不是运气差。这是 Go 服务最常见的线上问题之一：channel 阻塞导致 goroutine 泄漏。而"加 buffer"是社区里最流行、也最没用的解法。

buffer 只是把崩溃推迟了。问题的根因——谁在等谁、谁该退出、谁该 close——一个都没解决。

这篇文章做一件事：从"goroutine 涨了"这个信号出发，走一遍完整的排查路径，把 channel 的六个最常见陷阱逐个拆开。

不是背 API。

是下次线上出问题的时候，你知道先看什么。

发现：怎么知道 channel 卡住了

排查 channel 阻塞的第一步不是看代码，是看数字。

runtime.NumGoroutine()：最简单的基线

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import "runtime"

func init() {
 go func() {
 ticker := time.NewTicker(30 * time.Second)
 defer ticker.Stop()
 for range ticker.C {
 log.Printf("goroutines: %d", runtime.NumGoroutine())
 }
 }()
}

这段代码放到任何 Go 服务的 init() 里，每 30 秒打一行日志。goroutine 数量只升不降，大概率有泄漏。

Goroutine泄漏 on Zampo Blog

加 buffer 不是修 bug：Go channel 阻塞排查实战

发现：怎么知道 channel 卡住了

runtime.NumGoroutine()：最简单的基线