测量单个goroutine生命周期必须手动埋点，defer+time.Since可测函数执行时长，go tool trace能观测调度级全周期，runtime.GoroutineProfile无法获取时间信息且ID复用不可靠。
goroutine 没有内置生命周期监控机制
Go 运行时不会暴露单个 goroutine 的创建/退出时间戳，runtime.Stack() 或 runtime.NumGoroutine() 都无法追踪具体 goroutine 的存活时长。想“测量单个 goroutine 的生命周期”，必须靠你自己在启动和退出处手动埋点——没有捷径，也没有标准库函数能直接返回“这个 goroutine 活了多久”。
用 defer + time.Since 粗粒度计时最常用
适用于你完全控制 goroutine 启动逻辑的场景（比如自己写 go fn()），核心是在入口记录开始时间，在函数末尾用 defer 打点结束时间：
func worker(id int) {
start := time.Now()
defer func() {
duration := time.Since(start)
log.Printf("goroutine %d ran for %v", id, duration)
}()
<pre class="brush:php;toolbar:false;">// 实际工作
time.Sleep(100 * time.Millisecond)}
- 注意
defer必须在 goroutine 内部调用，不能在启动它的函数里 defer —— 否则测的是启动函数的耗时 - 如果 worker 可能 panic，
recover()要配合 defer 使用，否则 panic 会跳过 defer - 这种方案测的是“函数执行时长”，不是“goroutine 从调度器分配到销毁”的完整生命周期（比如被 runtime 抢占、休眠、等待 channel 的时间仍会计入）
想测更精确的调度级生命周期？得用 go tool trace
如果你真关心“从被 M 唤醒执行 → 到彻底退出调度队列”的全过程（含阻塞、抢占、GC 暂停等），go tool trace 是唯一可靠手段：
立即学习“go语言免费学习笔记（深入）”；
- 启动前加
trace.Start(os.Stderr)，并在程序退出前trace.Stop() - 运行后用
go tool trace trace.out查看可视化 timeline - 在浏览器中可筛选单个 goroutine（G ID），观察其所有状态切换（running / runnable / blocked / syscall / GC waiting）
- 注意：trace 本身有性能开销（~10%~20%），且输出文件巨大，**绝不能在生产环境长期开启**
别误用 runtime.GoroutineProfile 获取“实时生命周期”
runtime.GoroutineProfile() 返回的是当前存活 goroutine 的 stack trace 切片，它不包含时间信息，也无法区分新旧 goroutine（ID 会复用）。有人试图用两次 profile 差值来“推断” goroutine 存活时长，这是不可靠的：
- G ID 不是单调递增的，重启后重置，高并发下极易重复
- profile 采样是快照，两个快照之间可能有 goroutine 创建又退出，你根本抓不到它
- 无法关联起始与结束事件——你看到的只是“此刻它还活着”，不是“它活了多久”
真正需要细粒度观测时，老老实实埋点；需要系统级分析时，用 trace；别指望靠 profile 猜生命周期。
