协程泄漏需排除初始化波动和后台干扰通过 runtime.NumGoroutine() 快速初筛重点监控请求后不回落、压测后不恢复、长期单调上升三种情形配合三处日志、pprof debug2 查阻塞栈关注 chan receive/select/semacquire/IO wait 状态测试阶段用 goleak.VerifyNone 拦截泄漏内存上涨未必反映在 heap profile因 goroutine 会钉住大对象须结合 goroutine 栈分析生命周期。协程数持续上涨且不回落基本就是泄漏了——但得先排除初始化波动和系统 background goroutine 干扰否则容易误判。用 runtime.NumGoroutine() 快速确认是否真泄漏这不是最终证据但能帮你 5 秒内排除“假警报”。刚启动 HTTP 服务时看到 NumGoroutine() 突然跳到 120大概率只是 pprof、log、health check 等后台 goroutine 在初始化不是泄漏。真正要盯的是这三种情况单次请求处理完后数字没回落比如入口打点是 80handler 返回后还是 80压测结束后等待 30 秒总数仍比空闲态高一大截稳定运行几小时后数字呈单调上升趋势50 → 180 → 420建议在关键路径加三处日志log.Printf(goroutinesidle: %d, runtime.NumGoroutine())空闲、start请求进、done返回前别只采一次样。立即学习“go语言免费学习笔记深入”用 /debug/pprof/goroutine?debug2 抓阻塞源头默认的 ?debug1 只给统计摘要看不出谁卡在哪必须加 ?debug2 才输出完整调用栈。生产环境直接 curl 就行curl http://localhost:6060/debug/pprof/goroutine?debug2重点关注这些状态的 goroutine Cleanup.pictures 智能移除图片中的物体、文本、污迹、人物或任何不想要的东西