Go微服务接入Istio需对齐HTTP客户端与Sidecar：超时须用context.WithTimeout并配置DestinationRule；获取真实IP需启用X-Real-IP头及EnvoyFilter；链路追踪需otelhttp.Transport+手动传播trace上下文。
Go 微服务直接上 Istio 不是不行，但多数团队卡在“Service Mesh 没带来收益，反而让 http.Client 行为变诡异、超时逻辑失效、链路追踪断点频出”——根本原因是没把 Go 原生 HTTP 客户端和 Istio 的 Sidecar 流量劫持对齐。
Go 服务调用外部 API 时 http.Client 超时完全失效
Istio 默认启用双向 TLS 和透明代理后，Go 的 http.Client.Timeout 只控制到本地 localhost:15001（Sidecar 的入站 listener）的连接+读写耗时，不包含 Sidecar 到目标服务的真实网络往返。真实超时由 Istio 的 DestinationRule 中的 trafficPolicy.connectionPool.http.maxRequestsPerConnection 和 outlierDetection 共同决定，Go 层面感知不到。
- 现象：设置
client.Timeout = 2 * time.Second，但下游服务卡住 15 秒才返回context deadline exceeded - 正确做法：在
DestinationRule中显式配置trafficPolicy.connectionPool.http.idleTimeout和httpRequestTimeout；Go 侧改用context.WithTimeout包裹每个Do()调用 - 别依赖
http.Client.Timeout做业务级超时，它现在只是“发请求给 Sidecar”的超时
Istio 注入后 Go 服务的 net/http 日志里看不到真实客户端 IP
Sidecar 默认把所有入向流量打到 127.0.0.1:8080，Go 服务收到的 req.RemoteAddr 永远是 127.0.0.1:xxxx，X-Forwarded-For 头也可能被 Istio 自动覆盖或未透传。
- 必须在
Gateway或VirtualService中开启headers.request.set["X-Real-IP"] = "%DOWNSTREAM_REMOTE_ADDRESS%" - Go 服务里别再用
req.RemoteAddr，统一读req.Header.Get("X-Real-IP")， fallback 到X-Forwarded-For第一段 - 注意：Istio 1.17+ 默认禁用
useRemoteAddress，需在EnvoyFilter中手动开启，否则%DOWNSTREAM_REMOTE_ADDRESS%取到的是 Sidecar 地址而非原始客户端
Go 的 context.Context 跨服务传递时 TraceID 断掉
Istio 自带的 tracing（如 Jaeger）只注入 b3 或 w3c 格式的 headers，但 Go 标准库的 http.Client 不会自动把 context 中的 trace span 注入 outbound 请求头，除非你手动做。
立即学习“go语言免费学习笔记（深入）”；
- 现象：A 服务生成了 traceID，调用 B 服务后，B 的日志里
trace_id是新生成的 - 必须用
opentelemetry-go替代原生http.Client，或至少用otelhttp.Transport包装底层 transport - 关键点：不是加个 SDK 就行，要确保 Go 服务启动时调用
otel.SetTextMapPropagator(b3.New())（匹配 Istio 默认 propagator） - 别信 “Istio 自动透传”，它只透传，不生成、不注入、不关联 span —— 这部分必须 Go 代码自己扛
真正难的不是部署 Istio，而是让 Go 的每处 http.Client、每条 context.WithValue、每个日志字段，都和 Sidecar 的 header 注入/截获节奏对得上。错一个 header 名、漏一次 context 传递、少配一个 EnvoyFilter，整条链路就静默断裂。这种事没法靠 YAML 文件自愈，得一行 Go 代码一行 Envoy 配置地对。
