Go服务接入Istio无需修改业务代码，但必须监听0.0.0.0而非127.0.0.1，暴露/healthz等健康端点，确保istio-proxy注入成功并劫持流量，否则灰度、限流、mTLS等策略失效。
Go 服务接入服务网格，不等于要自己写一个 Envoy。绝大多数场景下，你根本不需要编译或绑定任何 Sidecar 代理——Istio 的 istioctl inject 或 auto-injection 机制会自动把 Envoy 容器注入 Pod，你的 Go 二进制只管监听端口、暴露健康检查，别的交给边车。
Go 应用本身要不要改代码才能进 Istio？
不用改。前提是：
- Go 服务监听的是
0.0.0.0:8080（不是127.0.0.1:8080），否则 Envoy 无法转发入向流量 - 暴露
/healthz或/readyz端点（哪怕只是返回200 OK），Istio 的 readiness probe 依赖它判断容器是否就绪 - HTTP 服务不要在 handler 里硬编码
Host或Origin头做校验——Envoy 会改写部分 header，比如把原始Host改成集群内 DNS 名 - gRPC 服务需确保使用
grpc.Dial时传的是逻辑服务名（如user-service.default.svc.cluster.local），而非 IP+端口；DNS 解析由 kube-dns + Istio 的ServiceEntry共同完成
什么时候才需要自己编译 Go 版 Sidecar？
极少数定制化场景，比如：
- 想绕过 Envoy，用 Go 实现轻量级 L4/L7 代理（例如只做 TLS 终止 + 路由，不支持 xDS 动态配置）
- 嵌入式设备或边缘节点资源极度受限，Envoy 的 ~50MB 内存开销不可接受
- 需要与特定硬件加速模块（如 DPDK）深度集成，而 Envoy 不支持
此时推荐基于 golang.org/x/net/proxy + net/http/httputil 搭骨架，但要注意：httputil.NewSingleHostReverseProxy 默认不更新 Host 头，必须重写 Director 函数；http.Transport 别设 MaxIdleConnsPerHost = 0，否则高并发下连接数爆炸。
立即学习“go语言免费学习笔记（深入）”；
Istio 注入失败的三个高频原因
Pod 里没出现 istio-proxy 容器？先查这些：
- Namespace 没打标签：
kubectl label namespace default istio-injection=enabled（不是istio-injection=on） - Deployment 的
spec.template.metadata.annotations里写了sidecar.istio.io/inject: "false"，覆盖了 namespace 级开关 - Go 镜像用了
scratch或alpine且没挂载/var/run/secrets/istio—— Envoy 启动时读不到证书，会 CrashLoopBackOff，日志里报failed to load root cert
Sidecar 和 Go 应用共享网络命名空间后，端口怎么分配？
这是最容易被忽略的底层细节：
- Envoy 默认监听
15090（Prometheus metrics）、15021（健康检查）、15010（xDS）、15012（SDS），这些端口由 Istio 控制平面管理，Go 应用不能占用 - 你的 Go 服务监听端口（比如
:8080）会被 Envoy 自动拦截——入向走15006（inbound listener），出向走15001（outbound listener），无需你在代码里调用localhost:15001 - 如果 Go 服务主动发起 HTTP 请求（比如调其他服务），默认走的是本机
localhost，会被 outbound listener 拦截并路由；但如果用了http.Transport并设置了DialContext，又没兼容 Istio 的 DNS 规则，可能直连失败
真正要操心的不是“怎么绑定”，而是“别碰那几个保留端口”和“别在 Go 里手动构造指向 localhost 的出向连接”。
