go-control-plane仅提供xDS协议骨架，需手动实现VersionInfo递增、Nonce生成及proto.Message资源封装；net/http无法支持HTTP/2多路复用、gRPC流控等数据平面必需能力。
go-control-plane 不是开箱即用的控制平面，它只提供 xDS 协议骨架，所有版本管理、资源 diff、nonce 生成都得自己补全。
为什么不能直接用 net/http 实现服务网格入口
Service Mesh 的数据平面必须支持 HTTP/2 多路复用、gRPC 流控、连接池级熔断和 TLS 终止——这些能力 net/http 标准库根本没提供。你写个 http.ServeMux 路由器，连 Envoy 都没法对接：它会拒绝你的响应，因为缺少 TypeUrl、VersionInfo 和合规的 Nonce 字段。真要落地，要么用 Envoy/Cilium eBPF 做 data plane，要么用 golang.org/x/net/http2 手动建流、劫持 net.Conn 层做透明重定向。
go-control-plane 实现 xDS v3 必须手动处理的三件事
用 go-control-plane 对接 Envoy 时，漏掉任意一项都会导致配置卡死或无限重试：
-
VersionInfo必须每次变更都递增（比如用哈希值或单调递增整数），Envoy 严格比对它决定是否接受新配置 -
Nonce必须随每次响应变化，且需回传请求中的node.id，否则 Envoy 认为响应无效 - 所有资源（
Cluster、Endpoint、Route）必须是proto.Message实例，不能是 map 或 struct —— 否则序列化失败
Sidecar 注入 webhook 容易被忽略的证书问题
Kubernetes admission webhook 必须用合法 CA 签发的证书，否则 kube-apiserver 拒绝调用。本地测试常用 cfssl 或 openssl 生成，但上线时务必用组织内受信 CA，且证书 Subject 中的 CN 必须匹配 webhook service 的 DNS 名（如 mesh-injector.default.svc）。另外，webhook 配置里 sideEffects 字段若设为 None，而实际修改了 Pod spec，会导致调度失败。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
指标采集别混用 registry，标签必须统一规范
Service Mesh 的可观测性依赖指标聚合，但 Go 生态里 prometheus/client_golang 的 Register 是全局单例。如果你在不同组件里各自 new 一个 Registry，Prometheus 抓不到数据。正确做法是整个 control plane 共享一个 registry，并用固定前缀（如 mesh_）和标准 label（service、cluster、direction）打标。比如熔断状态指标应为：mesh_circuit_breaker_state{service="order",state="open"}，而不是随意命名的 cbr_status。
立即学习“go语言免费学习笔记（深入）”；
真正难的不是写通 xDS 接口，而是让每个 sidecar 的健康状态、流量拓扑、策略变更能实时收敛——这要求你把 version、nonce、资源依赖关系全都串起来，稍有错位，整个 mesh 就静默失联。
