Go语言中Context实现跨API请求追踪的核心是将带唯一trace ID的context.Context实例从HTTP入口逐层传递至下游各环节，并在日志、指标和链路系统中统一提取与传播。1. 入口处用自定义key类型注入trace ID，避免字符串key冲突；2. 跨HTTP调用时通过http.NewRequestWithContext透传Context并手动设置X-Trace-ID头；3. 日志工具自动从Context提取trace ID关联输出；4. 集成OpenTelemetry等标准SDK实现分布式追踪可视化。
Go语言中使用Context进行跨API请求追踪，核心是把同一个context.Context实例（带唯一trace ID）从入口一路传递到下游HTTP调用、数据库查询、RPC等各环节，并在日志、指标、链路系统中统一提取和传播该ID。
1. 在HTTP入口生成并注入Trace ID
接收请求时创建带trace ID的Context，推荐使用context.WithValue或更规范的自定义key类型注入。避免用字符串作key，防止冲突：
type ctxKey string
const traceIDKey ctxKey = "trace_id"
func handler(w http.ResponseWriter, r *http.Request) {
traceID := r.Header.Get("X-Trace-ID")
if traceID == "" {
traceID = uuid.New().String()
}
ctx := context.WithValue(r.Context(), traceIDKey, traceID)
// 记录初始日志
log.Printf("request started: %s", traceID)
result, err := doBusinessLogic(ctx)
// ...
}
2. 跨HTTP API调用时透传Context和Trace ID
使用http.NewRequestWithContext将Context传入请求；同时手动把trace ID写入X-Trace-ID头，确保下游服务可读取：
- 必须用
req.WithContext(ctx)或http.NewRequestWithContext构造新请求，否则Context不生效 - 下游服务才能通过
r.Header.Get("X-Trace-ID")拿到ID，实现链路串联 - 若调用多个下游，每个请求都应复用同一Context（不是新建），以保持取消/超时信号同步
3. 在日志与中间件中自动关联Trace ID
封装日志工具，在打印日志前尝试从Context中提取trace ID，避免手动传参：
立即学习“go语言免费学习笔记（深入）”；
func Log(ctx context.Context, msg string) {
if id, ok := ctx.Value(traceIDKey).(string); ok {
log.Printf("[trace:%s] %s", id, msg)
} else {
log.Println(msg)
}
}
中间件中也可统一注入trace ID到log.Logger或结构化日志字段中，例如结合zap的With方法：
- 在中间件里提取
traceID，存入zap.Logger的With(zap.String("trace_id", id)) - 后续所有
logger.Info都会自动带上该字段，无需每处重复加
4. 配合OpenTelemetry或Jaeger做分布式追踪
单纯用Context + 自定义Header只能实现基础ID透传，要真正可视化调用链，需集成标准追踪SDK：
- 使用
go.opentelemetry.io/otel初始化TracerProvider，自动从Context提取span上下文 - HTTP客户端用
otelhttp.NewClient包装，自动注入traceparent头 - 服务端用
otelhttp.NewHandler包装handler，自动解析并续接span - 此时
Context中已含活跃span，业务代码可通过trace.SpanFromContext(ctx)获取并打点
Context本身不负责生成或传输trace ID，它只是安全携带和传递的载体；真正的追踪能力来自规范的ID生成、头字段约定、日志埋点和标准追踪系统的协同。不复杂但容易忽略细节。
