Kubernetes原生Service仅提供四层负载均衡和基础服务发现，不支持灰度、熔断、重试、链路追踪等服务治理能力；Ingress仅处理南北向流量，无法覆盖服务间东西向调用；硬编码服务地址会导致DNS缓存、连接失败、流量切分失效等问题。
Kubernetes原生Service只管四层转发和基础服务发现，Go服务直连user-service:8080这类写法，等于把拓扑写死，根本谈不上治理——你要的灰度、熔断、重试、链路追踪，它一个都不提供。
为什么不能靠Ingress或硬编码实现服务治理
Ingress-nginx只处理南北向流量（外部进集群），服务间调用走的是东西向，完全绕过它；EndpointSlice只是Endpoints的性能优化版，不增加任何策略能力；在Go代码里写死http://order-service:9000，会导致滚动更新时DNS缓存未刷新、Pod重启后连接失败、无法按标签切分流量等问题。
- HTTP 503频发但
kubectl logs -n istio-system -c pilot查不到路由配置错误，大概率是Ingress被误当服务网格用 - 发布v2版本后10%请求卡住15秒才返回，其实是没配
timeout: 5s和retries，Envoy默认无限等待 - 想给
v2-canary打1%流量，却在Deployment里加version: v2标签——Istio的VirtualService根本不认这个字段，得用subset+DestinationRule
Go服务接入Istio Sidecar的关键适配点
Sidecar注入后，流量自动经Envoy代理，但Go服务必须配合才能让治理能力生效。否则你看到的全是tcp_connection_open指标，没有http_request_duration_seconds，Kiali里所有调用都显示为unknown。
-
http.ListenAndServe("0.0.0.0:8080", handler)必须写成监听0.0.0.0，不能是127.0.0.1——Sidecar从localhost外发起连接，绑本地回环就收不到请求 - 健康检查路径如
/health必须返回HTTP 200且响应体非空（哪怕只返回{"ok":true}），否则Envoy会把Pod标记为NOT READY并剔除流量 - gRPC服务必须注册
grpc.UnaryInterceptor，否则Istio无法提取:path头，所有方法名在监控里都是unkn - HTTP handler里要显式注入
X-Request-ID和X-B3-TraceId头，OpenTelemetry SDK才敢把跨服务调用串成一条链
client-go调用K8s API做辅助治理的边界在哪
Go服务本身不管理微服务生命周期，kubernetes/client-go只适合写Operator、自定义控制器或运维工具。比如监听ConfigMap变更热更新限流阈值，或根据Pod状态自动触发告警——但它不能替代服务网格做实时流量调度。
- 不要在业务Handler里调用
clientset.CoreV1().Pods("default").List()查上游实例列表：DNS+Service已解决发现，再手动查是重复造轮子，还引入RBAC权限和性能瓶颈 - 若需动态调整路由规则，应通过
IstioOperator或kubectl apply -f virtualservice.yaml更新CRD，而非用client-go拼YAML再POST到/apis/networking.istio.io/v1beta1 - Finalizer清理、OwnerReference绑定这些Operator级操作，和业务服务无关，强行混在一起会导致关注点污染和升级困难
真正容易被忽略的是：Envoy对Go服务的可观测性支持，完全依赖你是否暴露了/metrics端点、是否结构化打日志、是否传递了trace头——这些不是“开了Istio就自动有”的功能，而是必须在Go代码里主动埋点。没这一步，服务网格再强大，你也只能看到TCP连接数，看不到哪个HTTP路径慢、哪个gRPC方法错得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
