字符串字段在trace context传播中不参与序列化，真正序列化的是W3C traceparent header的55字节ASCII字符串；手动拼接、日志冗余字段和goroutine中传递字符串trace ID才是性能瓶颈。
字符串字段在trace context传播中不参与序列化
Go分布式追踪里，trace_id、span_id这些标识符本身是二进制数据（[16]byte和[8]byte），不是字符串。W3C traceparent header 中看到的十六进制字符串（如00-4bf92f3577b34da6a3ce929d955d5808-00f067aa0ba902b7-01）只是传输时的编码形式，不是运行时上下文的存储形态。
真正被序列化/反序列化的，只有header值本身——也就是那一串ASCII字符。它长度固定（55字节），无论你用otel.GetTextMapPropagator().Inject()还是手动拼接，底层都只写入/读取这55个字节。你代码里定义的string变量（比如tid := "4bf92f3577b34da6a3ce929d955d5808"）如果没被注入到propagator，就完全不参与任何跨服务传输。
手动拼接traceparent字符串会引入额外开销
常见错误是绕过OpenTelemetry propagator，自己用fmt.Sprintf或strings.Join构造traceparent header：
- 每次请求都要分配新字符串，触发GC压力
- 十六进制编码/解码（如
hex.EncodeToString）比直接拷贝[16]byte慢3–5倍 - 小写字母转换（W3C要求小写）多一次遍历
- 无法复用OTel内部已优化的buffer pool，内存分配不可控
正确做法始终走标准流程：propagator.Inject(ctx, HeaderCarrier(req.Header))。它内部用预分配字节切片+unsafe快速写入，避免字符串中间态。
立即学习“go语言免费学习笔记（深入）”；
日志中字符串字段的开销远大于trace context
真正吃性能的是结构化日志里的字符串字段，比如你在zap.String("user_id", userID)里传入一个长字符串：
- 每个
zap.String调用都会复制字符串内容到日志encoder buffer - JSON序列化时还要做UTF-8校验、转义（如
"变成\"） - 如果
userID是128字节base64，最终日志体可能膨胀到200+字节 - 而
trace_id字段在日志里只是固定32字符，且通常复用同一段内存
所以别优化traceparent字符串——去检查你日志里那些动态拼接的error_msg、sql_query、request_body字段是否真的必要。
goroutine间传递字符串trace ID会导致context丢失
有人为“简化”，把trace_id从context.Context里抽出来当string参数传给goroutine：
go func(tid string) {
// 错误：这里没有span，没有采样决策，没有parent span id
logger.Info("worker start", zap.String("trace_id", tid))
}(traceIDStr)
这看似省了context传参，实际代价更高：
- 新goroutine的span变成root，链路断裂，下游服务收不到
traceparent - 日志里虽然有
trace_id字段，但无法关联到上游span的start/end时间、attributes、events - 如果该goroutine再发HTTP请求，必须手动重构造
traceparent字符串——又回到上一条的开销问题
正确方式永远是传context.Context，或至少传trace.Span实例（它线程安全，且自带完整context）。
最常被忽略的一点：trace context序列化开销几乎可以忽略，真正的瓶颈在日志字段冗余和goroutine上下文切断。别在traceparent字符串上折腾，先砍掉日志里那些未脱敏的req.Body和重复打印的stack trace。
