Go链路追踪应使用OpenTelemetry，而非runtime/trace：前者通过context透传实现跨服务trace-id串联，支持HTTP/gRPC/DB自动埋点与OTLP导出；后者仅记录单进程内goroutine调度、GC等运行时事件，不参与上下文传播，二者混用会导致链路断裂或工具失效。
Go 里链路追踪（Distributed Tracing）和 runtime/trace 是两套完全无关的工具，混用会直接失效：前者用于跨服务请求路径追踪（如 HTTP → DB → RPC），后者只记录单进程内 goroutine 调度、GC、系统调用等运行时行为。选错工具，连 trace 文件都打不开。
链路追踪该用 OpenTelemetry，不是 runtime/trace
OpenTelemetry Go SDK 是当前唯一被 Go 官方和主流云厂商（AWS、GCP、阿里云）共同推荐的链路追踪方案。它通过 context.Context 透传 span 上下文，支持自动注入（HTTP/gRPC）和手动埋点（DB、MQ、本地耗时），导出协议统一（OTLP），兼容 Jaeger、Zipkin、Lightstep 等后端。
而 runtime/trace 不处理任何 trace-id、span-id、parent-id，也不解析或传播 W3C Trace Context（traceparent header），压根不具备链路串联能力。
- 你用
trace.Start()生成trace.out，再跑go tool trace—— 看不到任何 HTTP 请求路径、DB 调用、服务名，只有灰色 Proc 条和零星 GC 事件 - 你在 HTTP handler 里调了
db.QueryContext(ctx, ...)，但没用go.opentelemetry.io/contrib/instrumentation/database/sql包包装 driver，那 DB 这一跳就断链 - 你用
go func() { ... }()启动协程却没传带 span 的ctx，新 goroutine 的 span 就是 root，父子关系丢失
runtime/trace 只适合分析调度延迟和运行时行为
runtime/trace 的真实用途是定位 Go 运行时级问题：goroutine 长时间处于 Runnable 却未被调度（调度延迟）、系统调用阻塞、锁竞争、GC STW 时间过长。它不记录函数名、不采样 CPU、不支持自定义 tag，也不能导出为 Jaeger 格式。
常见误用场景：
- 想靠它查 “哪个 HTTP handler 最慢” —— 不行，得用
net/http/pprof或otelhttp.NewHandler() - 把
trace.out丢进 Jaeger UI —— 报错unknown magic number，因为格式根本不兼容 - 在 init 函数里调
trace.Start()—— 静默失败，runtime初始化还没完成 - 写 trace 文件到 NFS 盘或 tmpfs —— 写入延迟导致采样失真，调度事件被过滤掉
链路追踪必须显式透传 context，runtime/trace 不参与
OpenTelemetry 的 span 生命周期完全绑定 context.Context。你调 tracer.Start(ctx, "db.query")，返回的 span 和新的 ctx 必须一起往下传；下游调 trace.SpanFromContext(ctx) 才能拿到 parent span 并关联。
而 runtime/trace 对 context 完全无感——它只监听 Go 运行时内部事件，不读、不写、不依赖任何用户传入的 ctx。
- HTTP 入口：用
otelhttp.NewHandler()中间件，自动从traceparent解析并注入 ctx - HTTP 出口：用
http.Client+otelhttp.Transport，自动注入 header - 数据库：必须用
otel.WrapDriver()包装原 driver，否则QueryContext()不会读 ctx 里的 span - goroutine：不能写
go doWork()，得写go doWork(ctx)，且ctx是从上游传来的，不是context.Background()
别在同一个程序里同时开 OTel 和 runtime/trace 采样
两者都会增加运行时开销：OpenTelemetry 在每次 span 创建/结束、event 记录、attribute 设置时做内存分配和原子操作；runtime/trace 则在每个 goroutine 切换、系统调用进出、GC 阶段变更时写缓冲区。同时启用容易触发 buffer overflow（runtime/trace 默认上限 200MB）或显著拖慢吞吐。
正确做法是分场景使用：
- 查跨服务超时、上下游依赖、错误传播路径 → 开 OTel，关
runtime/trace - 查 goroutine 积压、调度不均、sysmon 检测延迟高 → 关 OTel（或降采样率），开
runtime/trace，加runtime.SetBlockProfileRate(1) - 要同时看？先跑 OTel 收集完整链路，再单独启一个最小化服务复现问题，只开
runtime/trace分析运行时行为
最常被忽略的一点：OTel 的 TracerProvider 必须全局复用，runtime/trace 的 trace.Start() 必须在 main 开头就调、且确保 trace.Stop() 执行——前者不复用会导致 exporter 连接泄漏，后者不及时 stop 会导致文件末尾损坏，go tool trace 直接报 EOF。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
