创建 virtualservice 时需注意：hosts 必须为非 nil 的 []string；http 路由项必须是指针类型；weight 总和严格为 100；更新时须带 resourceversion 避免冲突；header 匹配区分大小写；gateways 字段需显式指定才能生效。
用 istio-go-client 创建 VirtualService 资源时，YAML 和 Go struct 映射容易出错
直接写 VirtualService 的 Go 结构体，比 YAML 多一层抽象，字段名、嵌套层级、指针/值类型不一致就会导致资源创建失败或路由不生效。
-
Hosts字段必须是[]string，空切片（[]string{}）和nil在 Istio 控制平面行为不同——后者可能被忽略，前者明确匹配空 host；生产环境建议显式设为[]string{"my-service.default.svc.cluster.local"} -
HTTP字段是[]*networking.HTTPRoute，不是[]networking.HTTPRoute：每个路由项必须是指针，否则 clientset.Create() 会静默丢弃该路由 - 权重路由（
Weight）总和必须严格等于 100，Istio 不做归一化——写成 70 和 25，流量会直接 fallback 到默认目标，而不是按比例分发 - 示例片段：
route := &networking.HTTPRoute{<br> Route: []*networking.HTTPRouteDestination{{<br> Destination: &networking.Destination{<br> Host: "reviews.default.svc.cluster.local",<br> Subset: "v2",<br> },<br> Weight: 70,<br> }, {<br> Destination: &networking.Destination{<br> Host: "reviews.default.svc.cluster.local",<br> Subset: "v3",<br> },<br> Weight: 30,<br> }},<br>}
在 Go 程序里动态更新 VirtualService，要避免 ResourceVersion 冲突和覆盖其他变更
Istio 的 VirtualService 常被多组件协同管理（如 CI/CD 工具、金丝雀发布系统、手动调试），直接 Update() 容易覆盖别人刚写的路由规则。
- 务必先
Get()当前资源，读取其ResourceVersion字段，再构造新对象并带上该版本号，否则会触发 “409 Conflict” 错误 - 不要全量覆盖
Spec.HTTP，而是用深拷贝 + 增量修改：比如只改某条路由的Weight，就遍历原HTTP列表找到对应项，修改后整体提交 - 如果多个 goroutine 并发更新同一资源，需加锁或使用
patch（如StrategicMergePatch），但注意 Istio CRD 不完全支持所有 patch 类型，推荐用client.Patch(ctx, vs, types.MergePatchType, patchData)
Go 中解析请求头做路由（如 headers["x-canary"] == "true"），要注意匹配逻辑和大小写
Istio 的 header 匹配默认区分大小写，且 Exact 模式不支持通配或正则，Go 代码里拼接条件时容易忽略这点。
-
Headers字段是map[string]*networking.StringMatch，key 是原始 header 名（如"x-canary"），value 必须是非 nil 的&networking.StringMatch{MatchType: &networking.StringMatch_Exact{Exact: "true"}} - Header 名在 HTTP/1.x 中本就是大小写不敏感的，但 Istio 控制平面目前按字面匹配——所以前端传
X-Canary，而 Go 里写了"x-canary"就不会命中 - 若需模糊匹配，只能用
Regex，例如&networking.StringMatch{MatchType: &networking.StringMatch_Regex{Regex: "^(?i)true$"}}，但 regex 性能略低，高频路由慎用
本地调试 VirtualService Go 代码时，Apply 成功但路由不生效的常见原因
资源创建返回 success，不代表 Envoy 已加载规则。很多问题卡在控制平面到数据平面的链路上。
立即学习“go语言免费学习笔记（深入）”；
- 检查目标服务是否打了
sidecar.istio.io/inject="true"label，没注入 sidecar 的 Pod 根本收不到 Istio 路由 - 确认
VirtualService的gateways字段：留空表示仅作用于 sidecar（mesh 内部），若想从 ingress gateway 生效，必须显式写[]string{"istio-system/istio-ingressgateway"} - 用
kubectl get virtualservice -o yaml核对实际提交的内容，尤其注意缩进错误导致的字段丢失（如把http写成Http，结构体能编译过，但字段不会被序列化） - 查日志：
kubectl logs -n istio-system deploy/istio-ingressgateway | grep "my-service"，看是否有 “no matching route” 或 “no endpoints found”
Weight 加起来是不是 100，ResourceVersion 是不是新鲜的，header key 的大小写有没有和真实请求对齐。这些点不报错，但一卡就是半天。 
