trace.start()必须配对trace.stop()，否则trace.out为空或仅头尾事件；须传*os.file（如os.create("trace.out")），禁用os.stdout；stop需执行到位，避免os.exit或panic跳过；应置于main()开头并加time.sleep留采集窗口；验证文件大小>1kb且为“go execution trace”类型。
trace.Start() 配对 trace.Stop() 是硬性前提
没这对调用，trace.out 就是空的或只有头尾两个事件——所有“打不开”“no trace events”的问题，90% 都卡在这儿。trace.Start() 必须传入一个可写的 *os.File，比如 os.Create("trace.out")；用 os.Stdout 或漏参数，数据只写内存缓冲区，不落盘。trace.Stop() 必须执行到，log.Fatal()、os.Exit(1) 会跳过 defer，结果文件无效。
常见补救方式：
- 把
trace.Start(f)放在main()开头，而不是http.ListenAndServe()之后——否则 handler 里的调度全丢 - 加
time.Sleep(200 * time.Millisecond)或select{}留出采集窗口，避免程序启动即退出 - 验证是否有效：
file trace.out输出应为Go execution trace，且ls -l trace.out显示大小 >1KB
go tool trace 必须走 HTTP 服务打开
直接双击 trace.out 或用浏览器打开 file:// 路径，会触发跨域限制，页面白屏或报 Failed to load trace: CORS error。正确做法是先运行：
go tool trace -http=:8080 trace.out
再访问 http://localhost:8080。端口可换，但不能省略 -http 参数。注意：trace.out 必须由 Go 程序用 runtime/trace 生成，不是文本日志，也不是其他工具输出的二进制文件。
Scheduler Latency 面板不出现？三个条件缺一不可
这个面板是查调度延迟的关键，但它默认不激活。必须同时满足：
- 启动前设置环境变量：
GODEBUG=scheddetail=1,schedtrace=1000 -
trace.Start()前调用runtime.SetBlockProfileRate(1)（值非零即可，这是隐藏触发开关） - 程序中真有阻塞行为（如
chan等待、sync.Mutex.Lock、net.Conn.Read），否则 runtime 不生成 sched 事件
缺任一条件，UI 只显示模糊的 “Proc Status”，不会出现 “Scheduler Latency” 标签页。Go 1.21+ 中 scheddetail 仍有效，但字段含义有调整（比如 runqhead 改为 runq 长度统计），别照搬老文档解读。
Goroutine 卡在 Runnable 状态，该看哪几个视图
灰色竖条就是调度延迟本身——Goroutine 处于就绪态但没被调度执行。重点盯：
-
Goroutines 视图：看每个 G 的
Runnable区段长度。持续 >1ms 就可疑 - Scheduler latency 面板：若某 P 的延迟分布持续偏高，可能是锁竞争或 GC STW 影响
- Network blocking / Synchronization blocking profile：确认是否集中在某个 fd、mutex 或 channel 上
注意：time.Sleep 不会出现在阻塞视图里（它属于主动让出 CPU），但 http.Get 中的 DNS 解析、TCP 握手、TLS 握手、body 读取都可能触发 syscall 阻塞。如果所有 P 的 runq 长度都接近 0，但 G 还是不 Running，问题大概率不在调度队列，而在 P 被抢占或 M 卡住（比如 cgo 调用未释放 P）。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
