根本原因是context.WithValue生成的上下文未被序列化到RPC请求中，需显式提取traceID并透传至metadata或请求体；正确做法是一次解析、一次注入，避免重复WithValue及字符串key冲突。
Go RPC 调用中 context 透传失败，traceID 消失了
根本原因不是 RPC 框架不支持，而是 context.WithValue 生成的上下文没被真正塞进 RPC 请求里。标准 net/rpc 和多数自研 RPC 库默认只传原始参数，context 是 Go 层的逻辑概念，不会自动序列化到 wire 上。
实操上必须显式把 traceID 提取出来，作为额外字段塞进请求结构体，或挂载到 metadata（如 gRPC 的 grpc.Metadata）；服务端再从入参或 metadata 中还原并注入新 context。
- gRPC 场景：用
grpc.InjectMetadata或手动调ctx = metadata.AppendToOutgoingContext(ctx, "trace-id", tid)发送；服务端用metadata.FromIncomingContext(ctx)取 - 自研 HTTP RPC：把 traceID 放在请求 header（如
X-Trace-ID），客户端加 header，服务端中间件解析后塞进context - net/rpc（少用但存在）：需改造
Client.Call封装层，在参数 struct 里硬加TraceID string字段，服务端 handler 开头提取并构建新context
用 context.WithValue 传 traceID 导致 goroutine 泄漏或内存暴涨
很多人图省事，在每个 RPC 入口直接 ctx = context.WithValue(ctx, "trace-id", tid)，但 WithValue 创建的是不可变链表节点，高频调用会堆积大量小对象，GC 压力大；更严重的是，如果 ctx 生命周期远长于单次 RPC（比如复用 long-lived worker goroutine），traceID 会污染后续所有调用。
正确做法是「一次提取，一次注入」：在入口（如 HTTP handler）从 header/metadata 解析出 traceID，立刻用 context.WithValue 构建一个干净的初始 ctx；之后所有子调用都基于这个 ctx 衍生，不再重复 WithValue。
立即学习“go语言免费学习笔记（深入）”；
- 禁止在 RPC 客户端封装函数内部做
WithValue，那会让 traceID 覆盖上级传入的 ctx - 避免用字符串字面量当 key（如
"trace-id"），定义为type ctxKey string; var TraceIDKey ctxKey = "trace-id"，防止 key 冲突 - 若用 zap/lumberjack 等日志库，确保 logger.With() 也基于该 ctx 中的 traceID，而不是从
WithValue里反复取
gRPC Interceptor 中获取不到 traceID，metadata.Key() 返回空
常见错误是用了 metadata.Pairs 但没注意大小写——HTTP/2 header 是 case-insensitive，但 gRPC 的 metadata.MD 默认只识别小写 key。如果你前端发的是 X-Trace-ID，服务端得用 md.Get("x-trace-id")，而不是 "X-Trace-ID"。
另一个坑是 client interceptor 和 server interceptor 的执行时机：client interceptor 在序列化前触发，server interceptor 在反序列化后、handler 执行前触发。如果 client 没加 metadata，server 端必然为空。
- 验证方法：在 server interceptor 里加
fmt.Printf("all keys: %+v\n", md)，看实际收到的 key 名 - 安全写法：统一约定用小写 key，如
"trace-id"，client 侧用metadata.Pairs("trace-id", tid)，server 侧用md.Get("trace-id") - 别依赖
metadata.FromIncomingContext(ctx).Get("trace-id")在 handler 里取——Interceptor 没注入的话，这里就是空，必须在 Interceptor 里完成注入
HTTP + JSON RPC 和 gRPC 混合部署时 traceID 格式不一致
HTTP 服务习惯用 X-Request-ID 或 X-B3-TraceId，gRPC 用 trace-id，两边不统一会导致链路断开。OpenTracing/OpenTelemetry SDK 默认不自动桥接这些 header，得手动对齐。
最轻量的做法是「入口标准化」：所有流量先过一层 gateway 或 middleware，把各种 header 统一转成内部约定的 key（如 trace-id），再注入 context；下游无论走 HTTP 还是 gRPC，都只认这一个 key。
- 不要让每个服务自己解析不同 header，维护成本高且易漏
- 如果用 OpenTelemetry，配置
otelhttp.WithPropagators和otelgrpc.WithPropagators使用同一种 propagator（如b3.New()），它会自动处理X-B3-*系列 header - 注意时间戳精度：HTTP header 里的 traceID 通常是字符串，gRPC metadata 也是字符串，但某些链路系统要求 traceID 是 16 进制 32 位，需提前校验格式，避免 downstream 解析失败
跨语言、跨协议的染色，真正的难点从来不在怎么传，而在于谁负责归一化、什么时候做归一化、以及归一化后是否被所有下游组件真正消费——漏掉任意一环，链路就断在那儿了。
