goland的“start profiling”抓不到协程泄漏，因其默认不触发/debug/pprof/goroutine?debug=2，仅做cpu或内存采样；需手动启用pprof服务并确保端口通、路由注册、参数带?debug=2，否则显示“no data”。
GoLand里点“Start Profiling”为什么抓不到协程泄漏
因为默认 profiling 模式不触发 /debug/pprof/goroutine?debug=2，它只做 CPU 或内存采样，不会拉取 goroutine 堆栈快照。你看到的“Goroutines”选项只是入口，背后没连上 pprof 的完整链路。
实操建议：
- 必须先在代码里导入
_ "net/http/pprof"，且服务监听了:6060（或你指定的内网端口） - GoLand 的
Run → Start Profiling → Goroutines实际执行的是curl http://localhost:6060/debug/pprof/goroutine?debug=2—— 如果端口不通、路由未注册、或没加?debug=2，它就只能显示“no data” - 别依赖 GoLand 自动启动 pprof server；手动加一行
go func() { http.ListenAndServe("127.0.0.1:6060", nil) }()更可靠
Profiler界面里右键“Filter by Stack Trace”搜什么才有效
搜 chan receive、select、semacquire、IO wait 这四类状态，不是搜函数名。pprof 返回的堆栈里，这些词直接标出阻塞位置，是协程泄漏最硬的证据。
常见误操作：
- 搜
http或client—— 太宽泛，几百个 goroutine 都会命中，无法聚焦 - 只看“Top Functions”，忽略状态字段 —— 一个函数可能正常运行，也可能卡死，状态才是关键
- 用
?debug=1（默认）抓数据 —— 它只返回统计摘要，没有调用栈，GoLand 过滤功能完全失效
火焰图双击跳转后，怎么判断是不是泄漏源头
双击跳转到源码行，只是帮你定位调用点，不是结论。重点看三件事：这行是否启动了新 goroutine、是否创建了 channel、是否用了无超时的阻塞原语。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
典型可疑模式：
-
go func() { ... }()闭包里调用了ch 或 <code>，但 channel 无人接收/发送 -
time.AfterFunc(...)注册后没配清理逻辑，或函数体里有无限循环 select { case 没写 <code>default，且ch已关闭或未初始化-
http.Client请求后没读完resp.Body，导致底层readLoop协程挂起
为什么goleak测试通过，线上还是泄漏
因为 goleak.VerifyNone(t) 只捕获测试生命周期内的“净新增”协程，对长期运行、后台常驻、或被 t.Parallel() 干扰的协程无效。
真实场景中容易漏掉的点：
- 全局 ticker：
time.Tick或time.NewTicker在init()里启动，测试根本覆盖不到 - HTTP server 启动后持续接受连接，每个连接 spawn 的 goroutine 不在测试 scope 内
- 第三方库的后台监控协程（如 opentelemetry、prometheus client），它们在
import阶段就启了，goleak.IgnoreCurrent()得提前拍快照 - 泄漏发生在压测后期（比如第 1000 次请求才触发 channel 关闭失败），单元测试根本跑不到那一步
线上协程泄漏最麻烦的地方不在技术手段，而在于它往往藏在“只运行一次”的初始化逻辑里，比如某个 sync.Once 保护的 setup 函数里漏掉了 defer wg.Done() —— 这种问题，pprof 能看到，goleak 看不到，GoLand 也标不出。
