go 的 trace 是采样式性能快照工具，非实时调试手段；需在 main 开头调用 trace.start 并确保 trace.stop 执行，配合 go tool trace 解析二进制文件，适用于分析调度、gc 等运行时行为，而非函数级耗时。
Go 的 trace 不是用来“实时调试”的，它是采样式性能快照工具，想靠它看单次函数调用耗时？会失望。
怎么启动 trace 文件生成
最常用的是在程序启动时加 runtime/trace 支持，不是用命令行参数开启——Go 没有类似 Python 的 -m trace 机制。
- 在
main函数开头调用trace.Start，并确保在退出前调用trace.Stop - 输出文件是二进制格式，不能直接读，必须用
go tool trace解析 - 别把 trace 文件写到 NFS 或慢盘上，写入延迟会污染调度采样结果
import "runtime/trace"
func main() {
f, _ := os.Create("trace.out")
trace.Start(f)
defer trace.Stop()
// ... your code
}
trace.Start 后没看到 goroutine 切换？
因为 trace.Start 只开启采样，但默认采样率很低（约 10ms 一次），短时间运行或纯计算型代码几乎捕获不到调度事件。
- goroutine 创建、阻塞、唤醒等事件依赖运行时的 hook，只有真正发生调度时才记录
- 如果程序秒级就退出，很可能只录到几个
GC或ProcStart事件，没实质内容 - 建议加
time.Sleep或循环逻辑，让程序跑够 2–5 秒再结束 - 不要在
init里 start trace——此时 runtime 还没准备好，会静默失败
go tool trace 打不开或报错 failed to open trace
常见于文件损坏、路径错误，或用了非标准方式写 trace（比如没 close、被截断、gzip 压缩过）。
- 确认 trace 文件大小 > 1KB；空文件或几十字节说明
trace.Stop没执行 - 别用
cat trace.out | go tool trace——该命令不支持 stdin，必须传路径 - Windows 下注意反斜杠路径，用正斜杠或双反斜杠：
go tool trace trace.out - 如果提示
failed to read trace: unknown magic number，基本是文件不是 trace 格式（比如误把 pprof 当 trace）
为什么浏览器里看不到函数耗时火焰图？
go tool trace 本身不提供火焰图；它展示的是 goroutine 调度、网络阻塞、GC、系统调用等底层运行时视图。想看函数级耗时，得用 pprof。
- trace 中的
View trace页面只能看到 goroutine 的状态变迁（running/blocking/gc），没有 CPU profile 那样的调用栈聚合 - 想定位热点函数，应该同时采集
pprof.Profile：用net/http/pprof或runtime/pprof - trace 和 pprof 是互补关系：前者看“谁在什么时候被调度”，后者看“哪段代码吃 CPU”
- 别试图用
trace替代pprof做性能优化，方向错了
真正难的不是启动 trace，而是理解它每条横线代表什么、为什么某个 goroutine 卡在 network poller 上、以及如何把 trace 时间轴和自己的业务逻辑对齐——这些没法靠文档自动推导，得反复比对、暂停、重放。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
