直接回答：trace 采集纳秒级事件流——goroutine 状态迁移（创建/运行/阻塞/唤醒）、STW、系统调用、网络轮询、GC 各阶段，工具（go tool trace）给出时间线视图与统计。看调度延迟的关键视图：Goroutine analysis 的 Execution（真正运行时长）与 Scheduler latency（就绪到上 CPU 的等待），后者大即调度供给不足。
展开解析：定位路径：某请求慢，trace 里找到对应 goroutine，若 Runnable 状态段长——就绪了没排上，查三个方向：GOMAXPROCS 相对负载太小（尤其容器 CPU 限额导致 runtime 按宿主机核数设置，1.25+ 用 automaxprocs 或 cgroup 感知）、长 STW（GC 辅助标记或 stack scan，看 trace 的 STW 段与 GC 报告）、个别 goroutine 长时间霸占 P 不让出（1.14 前纯计算循环无抢占点，之后基于信号的异步抢占基本解决，但 cgo 调用与大 memcpy 仍可能长占）。若 Network wait 长——IO 问题不是调度问题，别浪费方向；Sync block 长——锁或通道，转 block profile。采集注意：trace 开销比 pprof 大（5%~20%），窗口控制在几秒到十几秒，高并发服务文件膨胀快；线上用 flight recorder（1.21+ runtime/trace 的 FlightRecorder 环形缓冲）按需转储，异常时刻的现场不丢。统计视图也别错过：Scheduler latency 的直方图分布比均值更有信息量——p99 长尾尖刺常由周期性 STW 造成，与 GC 周期对齐即实锤。
追问方向：GOMAXPROCS 为什么不能简单设大？trace 与 pprof 的结论冲突时信谁？
（约 490 字）