Go服务需在Pod labels中显式声明version: v2，Consul注册时传metadata版本信息，HTTP响应头透传X-App-Version；Istio灰度依赖VirtualService headers match与DestinationRule subset标签匹配，且路由host须与Service全名一致。
Go服务怎么暴露版本标识给网关或Service Mesh
Go服务本身不自动带版本标签，必须显式注册或透传。否则Istio VirtualService或Consul查询时找不到v2实例，流量永远走不到新版本。
- 用Kubernetes部署时，在Pod的
metadata.labels里硬编码version: v2，这是Istio识别的基础 - 若用Consul注册，启动时必须传
metadata字段：map[string]string{"version": "v2", "env": "gray"} - HTTP服务需在响应头中透传版本信息（如
X-App-Version: v2），方便上游网关做二次校验 - 避免只改镜像tag（如
:v2）却不改label——K8s不会自动同步镜像tag到Pod label
如何让Istio按Header精准切流到Go灰度实例
Istio默认按权重轮询，但Header匹配才是灰度核心。VirtualService里写错一个字段，X-Canary就永远进不了v2。
-
match块必须用headers而非uri或sourceLabels，例如：headers: { "x-app-version": { exact: "v2" } } -
route目标必须指向带对应label的subset，而subset又依赖DestinationRule中定义的labels - 确保
DestinationRule的host与Service名称完全一致（包括命名空间，如app.default.svc.cluster.local） - 测试时用
curl -H "x-app-version: v2" http://your-service/，注意header名大小写——Istio默认区分大小写
Go内部做灰度判断时，哪些地方最容易阻塞主线程
在Handler里同步调用配置中心或DB查灰度规则，一卡就是几百毫秒，QPS直接掉一半。
- 灰度开关、比例等规则必须预加载到内存，用
sync.Map或atomic.Value缓存，避免每次请求都查etcd/Nacos - 用户ID哈希判断（如
hash % 100 ）要放在中间件最前，别等走到业务逻辑才判断 - 不要在
http.HandlerFunc里用time.Sleep模拟延迟测试——这会锁住goroutine调度器 - 若需动态更新规则，用watch机制（如
nacos.WatchConfig）触发atomic.StoreUint64更新，而非轮询
回滚时为什么旧版本Pod还在，但流量就是切不回去
不是K8s没删Pod，而是Istio的路由规则没清理干净，或者新规则残留了优先级更高的match条件。
- 执行回滚前，先
kubectl delete virtualservice canary-vs，再删destinationrule——顺序反了会导致503 - 检查是否有多个VirtualService匹配同一host，Istio按创建时间倒序生效，旧规则可能被新规则覆盖
- K8s Service的
selector如果还指着version: v2，即使删了v2 Pod，Service也会持续报No endpoints - 用
istioctl proxy-status确认Envoy配置已同步，有时控制面更新了，数据面Sidecar还没拉取
