无法直接统计单个goroutine执行耗时，因go未暴露其完整生命周期钩子；runtime.numgoroutine()仅返回总数，pprof仅提供无时间戳堆栈；go f()本身耗时纳秒级，测的是启动开销而非业务执行时长；需由业务代码在goroutine内部用defer+time.now()或trace.withregion主动埋点。
无法直接统计单个 goroutine 的执行耗时——Go 运行时没有暴露「某个 G 从创建到退出」的完整生命周期钩子，runtime.NumGoroutine() 只返回总数，pprof/goroutine 只给快照堆栈，不带时间戳。
为什么不能像函数那样用 defer + time.Now() 包裹 goroutine
goroutine 启动后立即返回，go f() 这行代码本身耗时极短（纳秒级），后续执行在另一个调度单元里。你在启动前记 start、启动后记 end，测的只是“发起协程”的开销，不是它干了什么。
- 常见错误：写
start := time.Now(); go func() { ... }(); fmt.Println(time.Since(start))—— 输出永远是几十纳秒 - 真正想测的，其实是「业务逻辑在该 goroutine 中实际运行了多久」，这必须由业务代码自己埋点
- 如果函数本身支持
context.Context，可在入口处记录time.Now()，退出前通过defer计算并上报，这是最可控的方式
用 trace.WithRegion 给 goroutine 执行块打标
trace.WithRegion 是目前最贴近「按 goroutine 划分耗时」的官方手段，但它依赖你主动把逻辑包进 region，且 region 生命周期需与 goroutine 对齐。
- 必须在 goroutine 内部调用：
region := trace.StartRegion(ctx, "my-task"); defer region.End() - region 名称会平铺显示，同名 region 会被合并统计，比如两个不同地方的
"db.Query"耗时会混在一起 - 启动 trace 需要提前调用
trace.Start(f)，输出文件用go tool trace trace.out查看，UI 上能定位到每个 region 的起止时间、是否被抢占、是否跨 P 等 - 注意：region 不自动继承 context，多个嵌套 region 需手动传 ctx 或靠命名区分层级（如
"cache.Get.redis"和"cache.Get.local"）
监控 goroutine 数量突增 + pprof 堆栈定位长耗时 goroutine
多数线上问题不是「单个 goroutine 太慢」，而是「大量 goroutine 卡住或堆积」。此时应放弃逐个计时，转为识别异常模式。
- 高频采样
runtime.NumGoroutine()（建议每秒一次），突增 3 倍以上触发告警 - 访问
/debug/pprof/goroutine?debug=2获取完整堆栈，筛选出状态为syscall、IO wait或长时间停留在某行代码的 goroutine - 结合
/debug/pprof/trace抓取 30 秒 trace，用 UI 查看哪些 region 持续运行、是否频繁阻塞在 channel 或 mutex 上 - 别只盯着 P99，
runtime.NumGoroutine()从 1k 涨到 10k 比接口慢 100ms 危险得多——它往往意味着泄漏或死锁
真正难的不是怎么记时间，而是判断「该不该记」：大多数 goroutine 本就不该有固定执行时长（比如处理 HTTP 请求、监听 channel），它们的耗时天然取决于外部输入。重点应放在识别异常生命周期（如超时未退出、重复创建不回收）和阻塞点，而不是给每个 go 语句配一个秒表。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
