goleak.VerifyNone(t) 必须用 defer 包裹在测试函数末尾，否则 panic 或提前 return 时不会执行；子测试需单独加 defer；手动启动的 http.Server 需显式忽略；channel 泄漏占 90%，需严控 close 时机与 nil/重复 close；线上用 pprof 定位泄漏；测试阶段应结合 -race、context 和 runtime.NumGoroutine() 预防。
goleak.VerifyNone(t) 必须放 defer 里，否则白加
测试中加了 goleak.VerifyNone(t) 却没报泄漏？大概率是它没执行到。因为 test panic 或提前 return 时，没被 defer 包裹的调用直接跳过了。
-
goleak.VerifyNone(t)要放在TestXxx函数末尾，并用defer包裹，确保无论成功失败都检查 - 别写成
goleak.VerifyNone(t); return这种直出写法——panic 时这行根本不会跑 - 如果用了
test.SubTest，每个子测试也得单独加defer goleak.VerifyNone(t)，父测试的不传递 - 默认会忽略标准库启动的 goroutine（比如
net/http的监听协程），但你手动启的http.Server不在白名单里，得显式忽略：goleak.IgnoreCurrent()或传goleak.Option
90% 的泄漏来自 channel 使用不当，重点盯这三件事
goleak 告诉你“有泄漏”，但堆栈往往停在 runtime.gopark 或 runtime.selectgo —— 实际问题八成出在 channel 生命周期管理上。
- 谁创建
chan，谁负责close()；向已close的 channel 发送数据会 panic，但接收还能读完缓冲区 + 零值 - 用
for range ch的 goroutine，必须由发送方关 channel；如果发送方不确定何时结束，改用select+donechannel 控制退出 - 别对
nilchannel 执行close()，也别重复close()，两者都 panic - 错误示例：
go func() { for range ch { ... } }()—— 若ch永远不关，这个 goroutine 就永远挂起
线上/集成环境没法用 goleak？pprof 是唯一能靠得住的入口
goleak 只能在单元测试里用，而线上或 CI 流水线中一旦发现协程数持续上涨，pprof 是唯一可落地的诊断手段。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 导入
_ "net/http/pprof"，再启一个 debug server：go func() { http.ListenAndServe("localhost:6060", nil) }() - 访问
http://localhost:6060/debug/pprof/goroutine?debug=2，重点关注堆栈末尾停在chan receive、semacquire、time.Sleep的 goroutine - 对比两次采集结果（间隔几十秒），新增且长期卡在相同位置的 goroutine，基本就是泄漏点
- 命令行也可用：
go tool pprof http://localhost:6060/debug/pprof/goroutine，进交互后输top看占用最多的函数
测试阶段就该预防：-race + context + runtime.NumGoroutine() 组合拳
等 goleak 报警才修，已经晚了一步。真正靠谱的做法是在开发和测试阶段就建立多层防线。
立即学习“go语言免费学习笔记（深入）”；
- 跑测试必加
go test -race，它能暴露因竞态导致的 goroutine 卡死（比如两个 goroutine 争抢关闭同一个 channel） - 凡是有长周期 goroutine（如 ticker、websocket handler、后台轮询），一律用
context.Context控制生命周期，而不是靠 channel 关闭信号 - 在关键路径打点：
fmt.Printf("goroutines: %d\n", runtime.NumGoroutine())，观察数量是否随请求完成回落 - 别依赖 “应该会退出” —— 每个 goroutine 启动前，先想清楚它收到什么信号才会退出，以及那个信号由谁发、什么时候发
