runtime/trace 看不到 goroutine 抢占式切换细节，因只记录 GoCreate、GoStart 等关键事件，GoSched 仅表主动让出；抢占切换由 go tool trace 解析聚合，非原始打点。
runtime/trace 为什么看不到 goroutine 切换细节
因为 runtime/trace 默认只记录调度器关键事件（如 goroutine 创建、阻塞、唤醒），不记录每次抢占式切换——那是 go tool trace 解析后才聚合展示的“逻辑切换”，不是运行时实时打点的原始事件。
想看到更细粒度的调度行为，得配合 GODEBUG=schedtrace=1000 环境变量跑程序，但它输出的是文本日志，和 runtime/trace 的二进制 trace 文件无关。
- 真正写入 trace 文件的 goroutine 相关事件只有：
GoCreate、GoStart、GoStop、GoSched、GoBlock、GoUnblock -
GoSched表示主动让出（如调用runtime.Gosched()），不代表所有调度切换；抢占触发的切换不会单独记为GoSched - trace 文件里看不到“哪个 P 抢占了哪个 M”这类底层调度器状态，那是
runtime.ReadMemStats或 pprof 调度器 profile 才能间接反映的
怎么正确启动 runtime/trace 并避免文件损坏
直接调用 trace.Start 后忘记 trace.Stop，或在程序退出前没 close file，会导致 trace 文件末尾截断，go tool trace 打开时报 failed to read trace: invalid trace data。
最稳妥的做法是用 defer 包裹 trace.Stop，且确保 trace 文件句柄在 main 函数结束前仍有效：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
import "runtime/trace"
f, _ := os.Create("trace.out")
trace.Start(f)
defer func() {
trace.Stop()
f.Close() // 必须先 Stop，再 Close
}()
- 不要在子 goroutine 中调用
trace.Start，它必须在主线程初始化 - trace 文件大小增长很快（尤其高并发场景），默认每秒写入数 MB，建议限制采样时间，比如只 trace 前 30 秒：用
time.AfterFunc(30*time.Second, trace.Stop) - 如果程序 panic 退出，
defer仍会执行，但若 panic 发生在trace.Start前，则无影响；反过来，若 panic 在 Start 后、Stop 前，trace 文件大概率损坏
go tool trace 看不到网络或磁盘 I/O 阻塞原因
runtime/trace 本身不采集系统调用耗时，它只记录 Go 运行时感知到的阻塞点：比如 net/http 底层调用 runtime.netpoll 进入休眠，会被标记为 GoBlockNet，但不会告诉你卡在 connect 还是 read，更不会显示 errno 或 syscall 名。
要定位具体 I/O 卡点，得结合其他工具：
- 用
go tool pprof -http=:8080 <binary> http://localhost:6060/debug/pprof/block</binary>查看阻塞在哪些调用栈（需程序开启net/http/pprof） - Linux 下可搭配
strace -p <pid> -e trace=connect,read,write</pid>看实际系统调用行为 -
GoBlockNet和GoBlockSyscall在 trace UI 里都显示为“Network”或“Syscall”色块，但无法区分是 DNS 查询慢、TLS 握手卡住，还是远端响应延迟高
trace 数据里 GC 标记阶段耗时异常，但 GOGC 没调低
GC 标记时间长，不一定是因为堆太大或 GOGC 设置过高。runtime/trace 中的 GCMark 事件包含 STW 和并发标记两段，其中并发标记阶段受 Goroutine 调度干扰明显——如果此时有大量活跃 goroutine 频繁分配对象，写屏障开销会显著拉长标记周期。
- 观察 trace UI 中
GCMark波形是否伴随密集的GoSchedule或GoStart，这是调度压力大的信号 - 不是所有 GC 都该被优化：一次
GCMark耗时 20ms 在毫秒级服务里算高，但在批处理程序中可能完全正常 - 降低
GOGC可能适得其反——更频繁的 GC 会增加写屏障总开销，反而抬高平均标记时间；优先检查是否有 goroutine 泄漏或缓存未限流导致对象分配暴增
trace 本身不提供内存分配热点，得靠 go tool pprof <binary><heap.pprof></heap.pprof></binary> 配合 top alloc_objects 或 top alloc_space 定位源头。这点容易被忽略：光盯着 trace 里的 GC 时间线，却没去查谁在疯狂 new。
