runtime/trace 不记录函数调用轨迹，仅捕获 goroutine 调度、gc、系统调用、网络/锁/channel 阻塞等运行时事件；函数级分析应使用 pprof，而非误用 trace。
runtime/trace 不记录函数调用轨迹，别误用
它根本不捕获函数进入/退出、参数、返回值或调用栈深度——runtime/trace 只记录运行时事件：goroutine 调度切换、GC 阶段、系统调用（read/write/openat）、网络阻塞、锁竞争、channel send/recv 阻塞点。想看 http.HandlerFunc 里哪一行耗时？该用 pprof.StartCPUProfile()；想查某次 os.ReadFile 是卡在磁盘还是调度器？trace 才能告诉你它是否长时间处于 Goroutine blocked on syscall 状态。
trace.Start() 的开销很小，但启停方式错就全废
启用本身几乎无 CPU 消耗（底层用原子计数器开关事件采集），但常见错误会让 trace 文件无效，白跑一趟：
-
trace.Start()传了os.Stdout或包装过的io.Writer：二进制数据混入日志文本，go tool trace直接报unknown magic number - 在
init()里调用：runtime尚未初始化，静默失败，文件空且无提示 -
main()开头就defer trace.Stop()：若程序逻辑快、没触发调度或 GC，trace.Stop()执行时缓冲区还没 flush 完，文件只有 header - 用
log.Fatal()或os.Exit(0)提前退出：跳过defer，trace.Stop()没执行，文件截断
真正影响性能的是 trace 数据量和采集窗口
trace 事件是按需生成的，不采样也不轮询，但高频系统调用或大量 goroutine 阻塞会快速撑大文件：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 每秒数万次
syscall.Syscall（如小文件高频读写）可能生成 MB 级 trace 文件，磁盘 I/O 成瓶颈 - 采集窗口太短（
time.Sleep(10 * time.Millisecond)）：默认采样间隔约 10ms，纯计算无阻塞逻辑可能只录到ProcStart和GCStart，看不出任何阻塞 - 生产环境反复启停：
trace.Start()/trace.Stop()本身轻量，但频繁创建/关闭文件句柄 + 内存 buffer 分配，在高 QPS 服务中会引入可测延迟
替代方案比硬套 trace 更有效
如果目标是函数级耗时分析，直接用对的工具：
- 查 CPU 占用热点：
pprof.StartCPUProfile()+go tool pprof -http火焰图，精确到行 - 查阻塞时间分布：
pprof.StartMutexProfile()或pprof.Lookup("block").WriteTo() - 动态抓取线上 trace：
import _ "net/http/pprof"后访问/debug/pprof/trace?seconds=20，避免重启 - 业务埋点打标：用
Prometheus.HistogramVec按op="read",path_prefix="/tmp/"维度上报，比 raw trace 更易聚合归因
trace 文件里看不到函数名，也看不到 time.Since() 的结果——它只回答“为什么没跑满 CPU”，不回答“哪段代码拖慢了”。真要定位函数，别绕路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
