/debug/pprof/goroutine?debug=2 无法反映峰值，因其仅返回当前时刻的 goroutine 快照，瞬时高峰易遗漏；需用 runtime.NumGoroutine() 配合滑动窗口（如30秒）采集历史最大值，并通过 Prometheus Gauge 暴露指标。
直接用 /debug/pprof/goroutine?debug=2 看实时堆栈，但峰值容易漏——它只拍快照，不记录历史高点。真要盯住“峰值”，得自己采样+聚合，不能只靠 pprof 默认接口。
为什么 /debug/pprof/goroutine?debug=2 无法反映峰值
这个接口返回的是当前时刻所有 goroutine 的文本堆栈（debug=2），每刷一次都是新快照。如果某次请求瞬间拉起 500 个 goroutine、200ms 后全退了，你刷新页面时大概率看到的还是 3–5 个 runtime 内部 goroutine，根本抓不到那个 500。
-
/debug/pprof/goroutine?debug=1返回的是二进制 profile，可用于go tool pprof分析，但它仍是单点快照，不带时间维度 -
runtime.NumGoroutine()是原子读，快是快，但值瞬变——没采集逻辑兜底，就等于没监控 - pprof 的
goroutineprofile 本身不采样“历史最大值”，它只统计“此刻活着的”
用 runtime.NumGoroutine() + 滑动窗口做峰值采集
把 runtime.NumGoroutine() 当作信号源，自己实现一个轻量滑动窗口，每秒取一次值，保留最近 N 秒的最大值。这才是线上可落地的峰值监控。
- 别在 metrics handler 里每次请求都调用并返回——虽然函数快，但 handler 阻塞会导致
/metrics卡住，影响 Prometheus 抓取 - 推荐用
time.Ticker每 1 秒触发一次采集：current := runtime.NumGoroutine()，然后更新全局变量maxInLast30s - 窗口长度建议 30 秒：太短（如 5 秒）易被毛刺干扰；太长（如 5 分钟）失去告警灵敏度
- 更新操作必须加锁或用
atomic.StoreInt64，因为 ticker goroutine 和 metrics handler goroutine 并发读写
把峰值暴露给 Prometheus
不要用 prometheus.NewGaugeFunc 包一层函数去动态算——这会让每次 scrape 都触发一次 runtime.NumGoroutine() 调用，且阻塞在 handler 里。
- 用
prometheus.NewGauge(prometheus.GaugeOpts{...})创建 gauge 实例 - 在后台 goroutine 中定期调用
gauge.Set(float64(maxInLast30s))，不是NumGoroutine()的实时值，而是你维护的那个滑动窗口最大值 - 务必调用
prometheus.MustRegister(gauge)，否则指标不会出现在/metrics输出中 - 指标名建议带后缀，比如
go_goroutines_max_30s，避免和默认的go_goroutines（即NumGoroutine()实时值）混淆
配合 pprof 定位峰值源头
光知道“峰值到了 892”没用，得立刻查清是谁干的。这时候才轮到 pprof 出场，但要用对时机：
- 当 Prometheus 告警触发（比如
go_goroutines_max_30s > 500），立刻手动 curl/debug/pprof/goroutine?debug=2—— 此时大概率还能复现现场 - 如果峰值已过，改用
/debug/pprof/goroutine?debug=1下载二进制 profile，再用go tool pprof -http=:8080 your-binary goroutine.pprof查看聚合堆栈 - 重点关注状态为
IO wait、semacquire、chan receive的 goroutine，它们卡在系统调用或同步原语上，才是真正拖住资源的“长尾” - 别只看数量多的堆栈——一个死循环 goroutine 只占 1 个，但可能吃光 CPU；而 200 个阻塞在
http.Get的 goroutine 才是泄漏信号
峰值监控真正的难点不在采集，而在定义“什么是异常峰值”：是绝对值破千？还是相比基线涨了 300%？这需要结合业务节奏打标，而不是设个固定阈值就完事。另外，pprof 的 goroutine 接口本身不加密、无鉴权，线上务必用反向代理加访问控制，别裸露在公网。
