goroutine泄漏是指启动的goroutine因永久阻塞或无法退出而持续占用资源。典型场景包括：向无缓冲channel发送数据但无接收者、for range未close通道、未用context监听取消信号、http超时缺失等；自查可用pprof查看chan receive/select阻塞状态。
Go 的并发模型不是“用 goroutine 就能自动高并发”，而是靠 GMP 调度器 + 显式控制 + 通信约定共同起效。盲目启动 goroutine 很容易吃光内存、卡死调度器，或让 channel 阻塞到程序假死。
goroutine 泄漏的典型场景和自查方式
最常见的泄漏是 goroutine 启动后永远等不到 channel 关闭或信号，比如：ch 发送到已关闭的无缓冲 channel 会 panic；<code> 从空且已关闭的 channel 会立即返回零值，但若逻辑依赖非零值就可能跳过清理；更隐蔽的是往一个没人接收的 channel 不断发数据（尤其带缓冲但容量设得过大），goroutine 就卡在发送端不动了。
- 用
runtime.NumGoroutine()在关键路径前后打点，看是否持续增长 - 用
pprof抓取 goroutine stack：curl http://localhost:6060/debug/pprof/goroutine?debug=2，重点关注状态为chan receive或select且长时间没变化的堆栈 - 所有带循环的 goroutine 必须有明确退出条件，避免用
for {}硬等
channel 缓冲区大小不是越大越好
缓冲 channel 看似能缓解生产消费速度差，但设太大等于把背压延迟到内存耗尽那一刻。比如 make(chan int, 100000)，一旦消费者卡住，10 万个 int 就占掉 800KB 内存，上万 goroutine 一拥而上直接 OOM。
- 无缓冲 channel（
make(chan T)）适合强同步：发送方必须等接收方就位，天然限流 - 有缓冲 channel 推荐按“单次批处理量”设，比如一次最多处理 128 条日志，缓冲设 128 即可
- 真正需要缓冲的场景，优先考虑用
worker pool+ 无缓冲 channel 控制并发数，而不是靠大缓冲扛流量
如何安全地限制 goroutine 并发数
用带缓冲的 channel 做信号量是最轻量、最 Go 风格的做法，但要注意 closure 捕获变量的坑。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
for i := 0; i —— 所有 goroutine 共享同一个 <code>i变量，最后全拿到 100 - 正确写法：传参进闭包
go func(id int) { ... }(i)，或用局部变量id := i; go func() { ... }() - 信号量 channel 必须用
struct{}类型，不占内存；释放操作一定要放在defer里，防止 panic 导致槽位永远不归还 - 如果任务有超时需求，别只靠
time.Sleep，要配合context.WithTimeout和select监听 done channel
GMP 调度器下容易被忽略的 CPU 密集型陷阱
Go 1.14+ 虽然加了抢占调度，但对纯计算循环（比如大数组遍历、加密哈希）仍不保证及时切换。一个 goroutine 占着 P 跑满 10ms，其他 goroutine 就得干等。
- 循环体内部每千次迭代调一次
runtime.Gosched()，主动让出 P - 更推荐拆分任务：把大计算切分成小块，每块跑完发一次结果到 channel，天然触发调度点
- 确认是否真需要 goroutine —— 如果是单核纯计算，开多个 goroutine 只会增加调度开销，不如直接 for 循环
-
GOMAXPROCS默认是 CPU 核心数，但 I/O 密集服务可以适当调高（比如 128），让阻塞的 M 更快被其他 P 复用
真正难的从来不是“怎么开 goroutine”，而是“什么时候不该开”以及“开完怎么收场”。channel 的零值、close 行为、select 的 default 分支，这些细节组合起来才决定并发逻辑是否健壮。写完记得用 -race 跑一遍，很多竞态问题 runtime 一跑就暴露。
