go中main退出时残留goroutine即内存泄露，需在退出前用runtime.numgoroutine()初判、goleak.verifynone(t)左移检测、pprof定位阻塞点。
Go 程序中，main 函数退出时残留的 Goroutine 就是明确的泄露——它们不会被自动回收，栈和关联资源（如 channel 缓冲区、文件句柄）会长期驻留，直到进程终止。检测必须在 main 退出前完成，治理核心是让每个 goroutine 拥有可触发的退出路径。
用 runtime.NumGoroutine() 快速确认泄露存在
这不是定位手段，而是第一道“有没有问题”的判断。在 main 函数末尾加 defer 打印数量，对比预期基线：
- 若程序逻辑上只应剩 1–2 个（比如仅
main和系统后台协程），但打印出明显更高的数字（如 5+），基本可断定有泄露 - 注意：该值包含 runtime 自身维护的 goroutine（如
net/http的监听器），不能直接等同于“业务泄露数”，但大幅偏离基线就是强信号 - 不要只测一次——加个循环启动/关闭子模块，观察数字是否持续增长
用 goleak.VerifyNone(t) 在测试中捕获泄露
这是开发阶段最有效的左移检测方式，专为单元测试设计，且只检查非系统 goroutine：
-
goleak.VerifyNone(t)必须放在defer中，否则测试 panic 时跳过，导致漏检 - 若测试中手动启了
http.Server或其他长期运行组件，需显式忽略：goleak.IgnoreCurrent()或传入goleak.Option过滤其堆栈 - 它不报错具体哪行代码泄漏，只告诉你“有残留”，需配合 pprof 进一步定位；但它能防止带泄露的代码合入主干
用 pprof 定位阻塞点与调用栈
当泄露已发生，pprof 是唯一能告诉你“卡在哪”的工具。关键操作不是看总数，而是看状态：
- 访问
http://localhost:6060/debug/pprof/goroutine?debug=2，重点找状态为chan receive、chan send、select或IO wait的 goroutine - 这些状态几乎都对应一个未满足的同步条件：通道没人关、
context没 cancel、无缓冲 channel 单边操作、time.Sleep无限等待 - 不要只看 top 函数——逐行 inspect 调用栈，找到那个没被触发的
close(ch)、没被调用的cancel()，或缺失的case
修复三类高频泄露模式
90% 的泄露集中在以下场景，修复要直击根源：
-
for range ch 阻塞：发送方未
close(ch)，接收方永远 hang 住。修复：确保发送方明确关闭通道；若发送方不确定何时结束，改用select { case v := -
context 未 cancel：调用了
context.WithCancel()或WithTimeout()，但忘了调用返回的cancel函数。修复：cancel必须在作用域结束前调用，推荐用defer cancel() -
nil channel 操作：对未初始化的
var ch chan int执行close(ch)或，会永久阻塞。修复：通道变量必须用 <code>make()初始化，禁止留空声明后直接使用
真正难的不是写 go func() { ... }()，而是写清楚它怎么停下来。所有泄露 goroutine 的共同点，是缺少一个被外部可观测、可触发、且必然执行到的退出分支。别依赖“程序退出时它自然死”，那只是掩盖问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
