最直接获取当前协程数的方式是 runtime.NumGoroutine()，返回活跃 goroutine 总数（含运行、就绪、阻塞及 runtime 内部协程），适合高频采样但需结合趋势判断泄漏；pprof/goroutine 提供结构化堆栈视图，诊断价值更高。
用 runtime.NumGoroutine() 获取当前协程数
这是最直接的方式，返回当前活跃的 goroutine 总数（包括正在运行、就绪、阻塞中的）。它开销极小，适合高频采样。
注意：这个数字包含 runtime 内部使用的 goroutine（比如 net/http 的监听协程、timerproc 等），实际业务 goroutine 数会略少。不要把它当作“泄漏判定唯一依据”，而应结合趋势观察——持续单向增长才值得警惕。
- 适合在健康检查接口（如
/debug/metrics）中暴露该值 - 搭配 Prometheus 用
go_goroutines指标更稳妥（它底层也调用此函数） - 避免在 hot path 中每毫秒调用一次，虽快但无必要
用 runtime.Stack() 抓取栈信息并估算大小
runtime.Stack() 本身不返回单个 goroutine 的栈大小，但它能导出所有 goroutine 的调用栈快照，配合字符串分析可粗略判断是否有异常大栈（比如深度递归、超大局部变量）。
典型用法是传入一个足够大的 []byte，让 runtime 把所有 goroutine 栈写进去：
立即学习“go语言免费学习笔记（深入）”；
buf := make([]byte, 1024*1024) n := runtime.Stack(buf, true) // true 表示获取所有 goroutine 栈 stacks := string(buf[:n])
关键点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 第二个参数为
true才会 dump 全量；false只 dump 当前 goroutine - 返回的
n是实际写入字节数，不是单个 goroutine 栈大小 - 无法精确得知每个 goroutine 的栈内存占用（Go 不暴露栈底/栈顶地址），只能靠日志里 “created by …” 和嵌套深度推测
用 pprof 查看 goroutine 堆栈和阻塞状态
比手动调用 Stack() 更实用的是启用 net/http/pprof，它提供结构化、可过滤的 goroutine 视图：
启动时注册：
import _ "net/http/pprof"
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()
然后访问 http://localhost:6060/debug/pprof/goroutine?debug=2，你会看到带完整调用栈的 goroutine 列表，按状态分组（running, syscall, IO wait, semacquire 等）。这比数字更有诊断价值。
-
?debug=1返回摘要（只列状态和数量） -
?debug=2返回全量栈，适合排查死锁或卡住的 channel 操作 - 生产环境建议限制访问 IP 或加 Basic Auth，避免敏感调用栈泄露
监控栈溢出或过深递归只能靠 panic 捕获和日志回溯
Go 运行时对栈大小是动态管理的（初始 2KB，按需增长），不会像 C 那样轻易栈溢出。但极端情况（如无限递归）仍会导致 runtime: goroutine stack exceeds 1000000000-byte limit 并 panic。
你无法提前“读取”某个 goroutine 的当前栈使用量，但可以：
- 在
init()或主入口加recover()捕获此类 panic，并记录debug.PrintStack() - 用
go tool trace分析长时间运行的 goroutine 是否有异常栈增长趋势 - 静态检查工具（如
staticcheck）能发现明显无终止条件的递归调用
真正难监控的是“隐式栈膨胀”：比如闭包捕获了巨大 struct、或 defer 链过长。这类问题得靠 pprof + 代码审查，没有一行函数能直接告诉你“这个 goroutine 占了 8MB 栈”。
