Go微服务对接Service Mesh无需改业务代码，但Envoy默认拦截所有端口导致健康探针超时，因Go服务监听localhost而Envoy无法loopback；修复需改监听地址为0.0.0.0或配置端口白名单。
Go 微服务直接对接 Service Mesh 不需要改一行业务代码，但默认配置下 Envoy 会拦截所有端口流量——包括健康检查探针、管理接口和调试端口，这会导致 kubectl get pods 显示 CrashLoopBackOff 或就绪探针持续失败。
为什么 Golang HTTP 服务的 /health 探针总超时？
根本原因不是 Go 代码慢，而是 Envoy sidecar 默认启用全端口透明代理，而 Kubernetes 的 livenessProbe 和 readinessProbe 发起的请求被拦截后，需经 Envoy 转发回本机——但 Go 服务监听的是 127.0.0.1:8080，Envoy 无法 loopback 回自身，形成“黑洞”。
- 最简修复：把 Go 服务监听地址从
localhost:8080改为0.0.0.0:8080 - 更稳妥做法：在
Deployment中显式声明readinessProbe.httpGet.port为容器端口，并确保该端口未被Envoy的excludeInboundPorts拦截 - Istio 1.21+ 可通过
sidecar.istio.io/inject注解配合traffic.sidecar.istio.io/includeInboundPorts白名单控制，避免误拦管理端口
Linkerd vs Istio：Golang 微服务选哪个 Sidecar？
不是功能多就好。Istio 功能全但 Envoy 内存占用高（单实例常驻 80–120MB），对小规模 Go 服务（如日志聚合、配置同步等轻量服务）属于资源浪费；Linkerd 的 linkerd-proxy 用 Rust 编写，常驻内存通常低于 30MB，启动更快，且默认禁用 mTLS，适合内部可信网络快速落地。
- 选 Istio：需要细粒度
VirtualService流量镜像、跨集群故障注入、或已深度依赖Kiali/Jaeger生态 - 选 Linkerd：团队追求极简运维、K8s 集群资源紧张、或 Go 服务本身已用
gRPC并自带 TLS - 避坑点：Linkerd 的自动 mTLS 依赖
identity组件，若 Go 服务使用自签名证书且未注入信任链，会导致503 USTAIL错误
Golang 里要不要自己实现重试/熔断？
不要。Service Mesh 已接管所有出向调用的重试、超时、熔断逻辑，你在 Go 代码里加 retry.Do 或 hystrix.Go 不仅冗余，还会和 DestinationRule 的 retries 配置叠加，导致实际重试次数翻倍甚至指数增长。
立即学习“go语言免费学习笔记（深入）”；
- 唯一例外：调用非 Mesh 管控的外部服务（如第三方支付 API），此时才需在 Go 层做兜底重试
- 验证是否生效：查
istioctl proxy-status确认 sidecar 连接正常，再用istioctl proxy-config cluster <pod>查目标服务是否出现在 outbound 列表中 - 注意：Go 的
http.DefaultClient会复用连接，若服务端突然断连，Mesh 层可能来不及刷新连接池，建议为关键调用新建带Timeout的http.Client
Sidecar 不是万能胶，它只管“怎么调”，不管“调什么”。契约变更、字段语义漂移、错误码滥用这些导致故障归因困难的问题，Mesh 压根不感知——它们藏在 Go 服务的日志和 gRPC proto 定义里，得靠人盯。
