不能，go tool trace 不提供调度延迟聚合指标，仅记录 goroutine 创建、运行、阻塞等原始事件；需从 ready 到 running 的时间差自行推算，并结合 schedtrace、trace.withscheduler、30 秒以上压测及 gc 控制来采集有效数据。
Go trace 工具能直接看到 goroutine 调度延迟吗？
不能。go tool trace 本身不提供“调度延迟”这个聚合指标，它只记录原始事件：goroutine 被创建、运行、阻塞、唤醒、抢占等时间戳。所谓“调度延迟”，是你得从 runtime.goroutines 和 scheduler 事件流里自己推算出来的——比如一个 goroutine 从就绪（ready）到真正开始执行（running）之间的时间差。
怎么抓到能反映调度压力的 trace 数据？
关键不是随便跑 go tool trace，而是用对采集方式和参数：
- 必须开启调度器追踪：
GODEBUG=schedtrace=1000只打文本日志，没用；要加runtime/trace.Start并显式启用trace.WithScheduler（Go 1.21+）或确保 Go 版本 ≥ 1.19 且未禁用调度事件 - 采样时间不能太短：调度延迟问题往往在负载波动时才明显，建议至少压测 30 秒以上，
trace.Start也得覆盖全程 - 避免干扰：关掉 GC 频繁触发（如用
GOGC=off临时控制），否则 GC STW 会掩盖真实调度延迟 - 示例启动方式：
go run -gcflags="-l" main.go && go tool trace trace.out
，其中main.go里调用了trace.Start并在结束前trace.Stop
在 trace UI 里怎么看调度延迟相关的线索？
打开 go tool trace 后，别只盯着火焰图。重点看三个视图：
- Goroutines 视图：找状态频繁切换的 goroutine（ready → running → runnable → blocked），拖动时间轴观察 ready 状态停留时长，>100μs 就值得怀疑
-
Network blocking profile 和 Synchronization blocking profile：虽然叫“blocking”，但里面大量
semacquire、chan receive等事件卡住后，会导致后续 goroutine 排队就绪却无法调度 - Proc status（按 P 查看）：如果某个 P 长时间空闲（idle），而其他 P 上 ready 队列积压严重，说明 work-stealing 失效或存在锁竞争，这是调度延迟的典型根因
为什么你看到的“延迟”可能根本不是调度问题？
很多标称“goroutine 调度延迟高”的现象，实际是别的瓶颈在冒充：
立即学习“go语言免费学习笔记（深入）”；
- GC 停顿（STW）：Go 1.22 之前 STW 可达毫秒级，期间所有 P 停摆，goroutine 不是“没被调度”，是整个世界暂停了
- 系统调用阻塞：比如
net.Conn.Read卡在内核态，goroutine 会 off-P，回来时需重新入队，这算 I/O 延迟，不是调度器的问题 - 锁竞争：
sync.Mutex或map并发读写导致 goroutine 在semacquire上排队，看起来像调度慢，其实是同步原语争用 - 注意：trace 里
runtime.mcall、runtime.gopark后紧跟着runtime.goready再到runtime.goexitsyscall，这种链路说明是系统调用返回路径，不是调度器卡点
调度延迟真要定位，得把 trace + pprof CPU + pprof mutex 对齐时间轴看，单靠 trace 一张图容易误判。
