<p>Istio Sidecar 自动注入需同时满足 namespace 标有 istio-injection=enabled 且 Pod 模板无禁用注解；Go 服务端口须在 Service 和 Pod 中以 http-/https- 前缀命名，否则流量不被劫持；X-Forwarded-For 是获取客户端 IP 的正确方式。</p>
Go 应用怎么让 Istio Sidecar 自动注入生效
Istio 的自动注入（auto-injection）不是“部署完就自动接管”，它依赖 Kubernetes 的 namespace 标签和 Pod 模板的注解共同触发。很多 Go 服务跑起来后流量没进 istio-proxy，根本原因是注入没发生，而不是代理配置错了。
- 确保目标
namespace打了istio-injection=enabled标签：kubectl label namespace default istio-injection=enabled --overwrite
- 检查你的 Go 应用 Deployment 是否含
spec.template.spec.containers—— 如果用了initContainers或自定义securityContext，Sidecar 注入可能被跳过（Istio v1.17+ 对某些字段更敏感） - 手动验证是否注入成功：
kubectl get pod -o jsonpath='{.spec.containers[*].name}'，输出里应该同时有你的 Go 服务名和istio-proxy - 如果用了 Helm 或 Kustomize 生成 YAML，确认没在模板里显式写死
sidecar.istio.io/inject: "false"这类覆盖注解
Go HTTP 客户端调用失败：Connection refused 是 Istio 还是代码问题
常见现象是 Go 服务用 http.Client 调其他服务时返回 dial tcp 10.x.x.x:80: connect: connection refused。这大概率不是网络不通，而是流量没走到 istio-proxy，或者 istio-proxy 没监听对应端口。
- Istio 默认只劫持
80、443等常见端口；如果你的 Go 服务监听的是8080但没声明端口名，istio-proxy不会拦截 —— 必须在 Service 和 Pod 的ports.name字段里加前缀，比如http-8080或https-8443 - 检查 Go 服务容器的
localhost调用是否走出了宿主机网络栈：用curl -v http://localhost:8080/health在容器内执行，若通但跨服务调用不通，说明是 Envoy 配置或 mTLS 策略问题 - 关闭 mTLS 临时验证（仅测试）：
istioctl install --set values.global.mtls.enabled=false
，避免因证书缺失直接拒绝连接
Go 应用日志里看不到真实客户端 IP，X-Forwarded-For 怎么取才对
Istio 的 istio-proxy 默认会在请求头里加 X-Forwarded-For，但 Go 的 http.Request.RemoteAddr 仍是 127.0.0.1:xxx（因为流量经本地 proxy）。别直接 parse RemoteAddr，它不可信。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先从
req.Header.Get("X-Forwarded-For")取值，但注意它可能是逗号分隔的多个 IP（如"203.0.113.195, 198.51.100.1"），最左边才是原始客户端 IP - 如果启用了 strict mTLS，Istio 会默认清理部分 header；需要在 DestinationRule 里显式开启：
trafficPolicy: { loadBalancer: { simple: LEAST_CONN }, portLevelSettings: [{ port: { number: 8080 }, connectionPool: { http: { h2UpgradePolicy: UPGRADE } } }] }（实际需配合proxy.istio.io/config注解启用 header 透传） - 不要依赖
X-Real-IP—— Istio 默认不设这个 header，除非你用 EnvoyFilter 显式添加
为什么 Go 服务升级后 Istio Metrics 里 HTTP 4xx 突增
不是业务逻辑改了，而是 Go 应用的 HTTP handler 返回了非标准状态码（比如 http.Error(w, "bad", 499)），而 Istio 的指标采集器（Prometheus）只识别 RFC 定义的标准状态码范围（1xx–5xx 中的已注册码）。499 被当成未知状态，打点失败或归为 unknown，导致监控看板里 4xx 曲线异常跳变。
立即学习“go语言免费学习笔记（深入）”；
- 检查所有
http.Error和w.WriteHeader()调用，把非标准码（如 499、422 以外的 4xx）换成标准码：499 改成 400 或 408，422 建议保留（Istio v1.16+ 已支持） - 确认 Go 应用没在 response body 写完前就调用
w.WriteHeader()—— 这会导致istio-proxy记录为503 UH（Upstream Health），而非你预期的 4xx - 用
istioctl pc routes <pod-name>查看当前路由配置，确认没有因 host 匹配失败导致 fallback 到 404 或 503
container.port.name 的命名规则和 namespace 的 injection 标签是否实时同步 —— 这两个点不满足，后面所有流量治理、可观测性都建立在沙上。 
