runtime/trace不用于查函数耗时，而是记录goroutine调度、GC、系统调用等运行时事件；trace.out为空或过小主因是trace.Stop()未执行或程序过快退出，且默认10ms采样率需实际调度/IO/GC才能生成有效数据。
runtime/trace 不是用来查函数耗时的，它记录的是 Go 运行时事件——goroutine 调度、GC、系统调用、网络阻塞等。想看 http.HandlerFunc 执行了多久？别指望 go tool trace 自动标出来；想定位 channel 死锁？它能帮你看到 goroutine 卡在哪类阻塞上。
trace.Start 后为什么 trace.out 是空的或只有几个字节
最常见原因是 trace.Stop() 没执行，或程序太快退出，没来得及写入有效事件。
-
trace.Start()启动后默认采样率约 10ms 一次，纯计算、无 goroutine 切换、无 I/O、无 GC 的代码几乎不产生数据 -
defer trace.Stop()放在main开头没问题，但若main里有os.Exit(0)或 panic，defer不会触发 → 文件截断 →go tool trace报EOF或unknown magic number - 文件大小
- 别用
os.Stdout或log.Writer()接trace.Start()，混入日志会导致解析失败
生成 trace.out 的最小可靠写法
以下代码能稳定产出可解析的 trace 文件，适用于测试和轻量服务：
package main
<p>import (
"os"
"runtime/trace"
"time"
)</p><p>func main() {
f, _ := os.Create("trace.out")
defer f.Close()</p><pre class="brush:php;toolbar:false;">_ = trace.Start(f)
defer trace.Stop()
// 至少触发一次调度：起 goroutine + 主动让出
go func() { time.Sleep(10 * time.Millisecond) }()
time.Sleep(100 * time.Millisecond)}
- 必须显式调用
trace.Start(f)，传*os.File，不能传路径字符串 -
trace.Stop()内部已调f.Close()，所以不用再defer f.Close()（但留着也不冲突） -
time.Sleep不是装饰——它确保 runtime 有时间写入事件；短于 100ms 很可能只录到ProcStart和GCStart - 避免在
init()里调trace.Start()，此时 runtime 尚未初始化，会静默失败
go tool trace 打不开或界面卡死怎么办
不是浏览器问题，而是 trace 文件本身或加载方式不对。
- 双击
trace.out或拖进 Chrome 会失败 ——go tool trace必须通过命令行启动：运行go tool trace trace.out，它会自动开http://127.0.0.1:8080 - 如果卡在 loading，大概率文件 >50MB（比如高频 timer 或 netpoll 事件爆炸），改用
go tool trace -http=:8081 trace.out换端口，或加-pprof=sync导出 pprof 分析更轻量 - Windows 下路径含空格或中文？用短路径或把
trace.out放到C:\tmp\这类干净路径 - Go 版本不匹配：1.22 编译的程序生成的 trace 文件，不能用 1.21 的
go tool trace解析
View trace 页面看不到函数名，只看到 goroutine ID 怎么办
这是设计使然，go tool trace 从不记录函数符号或调用栈 —— 它只记录运行时事件的时间戳和类型。
- 想看
db.Query耗时？得用runtime/pprof或net/http/pprof采集 CPU profile - 想在 trace 里标记业务阶段？用
trace.WithRegion(ctx, "db-query")+region.End()，会在 Events 视图中显示自定义标签 -
trace.Log(ctx, "cache-miss", "user-123")开销约 50ns，比fmt.Println快一个数量级，但每毫秒打点超百次仍会影响性能 - 真正要分析“谁在阻塞调度器”，重点看
Goroutines视图里的Runnable delay柱状图，而不是盯着某条 goroutine 的 running 时间
trace 的价值不在“看到函数”，而在“看清调度”。很多线上延迟毛刺，根源是 GC STW、netpoll 阻塞、或 GOMAXPROCS 设置不当导致 runnable 队列积压——这些在 View trace 里一目了然，但在 pprof 火焰图里根本不会出现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
