Go HTTP客户端默认不透传X-Request-ID等自定义Header，因HTTP/1.1规范限制及Istio Envoy白名单过滤；需显式设置Header、正确配置HTTP_PROXY走Sidecar、用context传递而非依赖请求头、gRPC需手动映射metadata。
Go HTTP客户端默认不透传 X-Request-ID 等自定义Header
Service Mesh（如Istio）依赖特定Header传递链路上下文，但Go标准库的http.Client在重定向或中间代理（如Envoy）介入时，会主动过滤掉非标准Header。这不是Bug，是HTTP/1.1规范要求：客户端不得随意转发未声明为“hop-by-hop”的字段。
常见现象：X-B3-TraceId、X-Request-ID、X-Envoy-Original-Path 在跨Sidecar后消失；调用链断开，Jaeger里只看到单跳。
- 必须显式在
http.Request.Header中设置，且不能依赖中间件自动注入 - 若用
http.RoundTripper封装（比如加了retry逻辑），需确保req.Header被完整传递，而非新建http.Request时漏掉 - Istio默认只透传白名单Header（见
meshConfig.defaultConfig.proxyMetadata.ISTIO_META_REQUEST_HEADERS），不在列表里的Header会被Envoy静默丢弃
用 context.Context 携带Header比用全局变量更可靠
很多人习惯在Handler里从r.Header.Get("X-Request-ID")取值，再塞进下游请求——这在单层调用没问题，但一旦涉及异步任务、goroutine分发、或中间加了cache层，Header就容易丢失或错乱。
正确做法是把关键Header提前解析并存入context.Context，后续所有下游调用（HTTP、gRPC、DB日志）都从ctx里取，而不是反复读http.Request.Header。
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithValue(ctx, key, value)存X-Request-ID、X-B3-SpanId等，key建议用私有类型避免冲突 - 下游HTTP请求构造时，从ctx中取值并显式写入
req.Header.Set()，不要依赖“继承” - 注意：gRPC的
metadata.MD和HTTP Header语义不同，跨协议传递时需手动映射，不能直接复用同一份ctx value
net/http.Transport 的 Proxy 配置影响Header透传路径
本地开发常设http.DefaultTransport.Proxy = http.ProxyFromEnvironment，但K8s Pod里Sidecar（如Envoy）监听的是127.0.0.1:15001，若Go程序没配对的HTTP_PROXY，请求就绕过Sidecar直连上游，Header自然不会被Mesh处理。
错误表现：本地能链路追踪，上线后全断；curl测正常，Go程序调用失败。
- 确认Pod内
HTTP_PROXY环境变量指向Envoy的inbound端口（通常是127.0.0.1:15001） - 检查
http.Transport是否被自定义覆盖，导致忽略HTTP_PROXY——例如用了&http.Transport{Proxy: http.ProxyURL(...)}却没设对地址 - Envoy默认只拦截
outbound流量（即Pod往外发的请求），inbound（外部进来的）由iptables接管，所以Go服务作为server时Header由Istio自动注入，但作为client时必须走Proxy才进mesh
gRPC-go 默认不传播 metadata 到HTTP Header
Go服务同时暴露HTTP和gRPC接口时，常想让X-Request-ID在两种协议间自动透传。但gRPC-go的metadata.MD和HTTP Header是隔离的，即使用了grpc.WithInsecure()直连，也不会自动把HTTP Header转成gRPC metadata，反之亦然。
典型坑：HTTP入口拿到X-Request-ID，调gRPC下游时没手动塞进metadata.Pairs()，结果下游gRPC服务日志里request_id为空。
- HTTP Handler中解析Header后，用
metadata.Pairs("x-request-id", reqID)构造metadata.MD - 调用gRPC方法时，用
grpc.Metadata(md)塞进ctx，不是ctx.WithValue() - 若下游是Go gRPC服务，可用
grpc_middleware.ChainUnaryServer()+ 自定义拦截器，把metadata里的x-request-id再写回HTTP响应Header（如果它也暴露HTTP接口）
Header透传真正的复杂点不在代码怎么写，而在于每个环节的信任边界：HTTP规范限制、Sidecar拦截规则、gRPC协议抽象、还有开发者对“上下文该从哪来”的直觉偏差。少一个环节显式传递，链路就断一截。
