接入 OTel 压测延迟直接涨了 15%，聊聊 Go 微服务链路追踪的落地复杂度与性能坑

最近在把组里的几个 Go 微服务接入 OpenTelemetry，搞得有点头大，想和大家对对账。

最大的体感就是：心智负担重，且性能损耗比想象中明显。

自己写了个基准测试跑了一下最基础的 span 注入开销：

• 纯空逻辑：~12 ns/op，0 B/op，0 allocs/op
• 套一层 tracer.Start(ctx, "test") 搭配批处理导出器（ParentBased(AlwaysSample)）：直接飙到 ~420 ns/op，288 B/op，4 allocs/op
• 就算采样率配成 0，做 Context 查找和包裹也是有几十纳秒的固定开销。

在几十万 QPS 的核心网关和并发聚合层，这些额外的 heap allocs 累加起来，GC 压力肉眼可见地抬上去了。

再就是代码侵入性，为了不丢 trace ID，几乎所有内部函数都要硬塞 ctx context.Context，漏传一个 trace 就断成两截。而且 OTel 的 Go SDK 那套 API / SDK 分离和 Provider 的配置逻辑，繁琐程度快赶上 Java 这一套了。

想请教下各位老哥：

1. 你们线上核心服务是怎么做权衡的？只在 HTTP/gRPC 中间件和 DB/Redis 驱动层打 trace，内部业务逻辑完全不启 span 吗？
2. 采样率（Ratio-based）一般给到多少才能在定位问题和性能开销之间找到平衡？
3. 有没有搞过自动化注入或者更轻量替代方案的玩法？