Go服务接入Istio需确保istio-proxy注入并生效：检查Pod中istio-proxy状态为Running且Ready为true，日志显示监听15001/15090端口，tcpdump验证流量命中15001或15006端口；Go须监听0.0.0.0而非127.0.0.1，Service targetPort需匹配实际端口，调用使用FQDN，HTTP/gRPC需透传trace header。
Go 服务接入 Istio 不需要改一行业务代码，但必须确保 Pod 注入了 istio-proxy 容器，且流量能被 Envoy 正确劫持——否则所有流量治理策略（灰度、限流、mTLS）全部失效。
怎么确认 istio-proxy 真正注入并生效
很多人看到 kubectl get pod 显示 2/2 就以为万事大吉，其实只是容器启动了，不等于流量走通。
- 先看容器状态：
kubectl describe pod <pod-name>中确认istio-proxy容器的State是Running，且Ready为true，没有CrashLoopBackOff或OOMKilled - 再查日志：
kubectl logs <pod-name> -c istio-proxy | grep "started"，应有类似transport: listening on 15001和admin: listening on 15090的输出 - 最关键一步：进容器抓包验证流量路径：
kubectl exec -it <pod-name> -c istio-proxy -- tcpdump -i any port 15001 or port 15006 -c 2，然后从另一 Pod curl 你的服务，应能看到数据包命中15001（inbound）或15006（outbound） - 如果
tcpdump没抓到包，大概率是 Go 服务绑定了127.0.0.1:8080而非0.0.0.0:8080，或者 Kubernetes Service 的selector标签没对上
Go 服务监听地址和端口配置陷阱
Envoy 只能拦截发往 Pod IP 的流量，无法处理 localhost 回环请求。很多本地调试习惯会直接写 http.ListenAndServe("127.0.0.1:8080", handler)，上线后就彻底失联。
- 必须监听
0.0.0.0:8080（或从环境变量读取端口后拼接），否则 inbound 流量进不来 - 端口不要硬编码；用
os.Getenv("PORT")，默认 fallback 到"8080"，这样能兼容 Istio 默认的containerPort映射逻辑 - Kubernetes Service 的
targetPort必须与 Go 实际监听端口一致；若 Go 启在8081，而 Service 写的是8080，则 Envoy 会转发失败并返回 503 - 健康检查探针（liveness/readiness）可放心用
http://127.0.0.1:8080/healthz，这是 Istio 显式放行的例外路径，不会被劫持
出向调用为什么连不上其他服务
常见现象：Go 里用 http.Get("http://other-svc:8000/api") 返回 dial tcp: lookup other-svc on 10.96.0.10:53: no such host 或连接超时，不是 DNS 问题，而是流量没进 proxy。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 确保调用地址用的是 Kubernetes FQDN：
other-svc.default.svc.cluster.local，而非短名other-svc（某些 DNS 配置下短名解析失败） - 目标服务必须存在对应的
Service资源，哪怕只是 headless service；Istio 不会为不存在 Service 的 Pod 建立 outbound 路由 - 若目标端口非标准（如
9090），必须在 Service 中显式声明appProtocol: http或grpc，否则 Envoy 默认按纯 TCP 处理，丢失 HTTP 层重试、路由等能力 - 避免用
http.DefaultClient直连localhost或127.0.0.1—— 这类请求绕过 iptables 规则，完全不经过istio-proxy
分布式追踪断链的典型原因
Istio 的 Jaeger 链路里只有 istio-proxy 的 span，看不到 Go handler 的 span，说明上下文没透传。
- Go 的 HTTP handler 必须从
r.Header读取x-request-id、x-b3-traceid、x-b3-spanid等 header，并在调用下游时原样透传；否则 trace 在第一个 hop 就断了 - 不要依赖框架自动透传（比如某些 Gin 中间件未开启 tracing 支持），建议手写一个基础 middleware：
w.Header().Set("x-request-id", r.Header.Get("x-request-id")) - gRPC 场景下，需用
grpc.WithUnaryInterceptor注入 context 传递逻辑，否则 OpenTelemetry SDK 拿不到上游 trace context - 日志中不打印
trace_id不仅影响排查，还会导致 Prometheus metrics 缺少destination_canonical_service等关键 label，Istio 的指标聚合失效
真正难的从来不是写几行 Go 代码，而是让每条请求都按预期路径穿过 Envoy；一次绑定地址错误、一个 header 漏传、一个 Service 配置遗漏，都足以让整个网格“静默失效”。
