envoy不写go，但go负责控制平面策略生成与下发，envoy执行数据平面流量控制，二者通过xds协议通信；go可生成xds配置、开发wasm插件（限http头/体操作）、补位轻量sidecar，但不可替代envoy核心能力。
Envoy 本身不写 Go，但和 Go 配合做流量治理时，关键不在“用 Go 写 Envoy”，而在于：Go 负责控制平面策略生成与下发（比如动态路由、熔断阈值、限流规则），Envoy 负责数据平面执行；二者通过 xDS 协议通信。硬要把 Go 塞进 Envoy 进程里跑逻辑，反而破坏隔离性、增加调试成本。
Envoy 的配置不能用 Go 直接写，但可以用 Go 生成
你没法在 envoy.yaml 里写 if req.Header.Get("X-Canary") == "true" —— Envoy 不解析 Go 表达式。但你可以用 Go 程序读取业务规则（比如从数据库或配置中心拉取灰度策略），然后渲染出符合 xDS 格式的 JSON/YAML，再推给 Envoy。
- 推荐用
github.com/envoyproxy/go-control-plane：它提供标准的 xDS proto 结构体和 gRPC server 模板，避免手拼 JSON 出错 - 不要每次改一个权重就全量推送
RouteConfiguration，用DeltaDiscoveryRequest只更新变更字段，减少控制平面压力 - 注意版本兼容：Go SDK 的 proto 版本必须和 Envoy 实例的 xDS API 版本对齐（如 v3 对应
envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager）
Go 编写的 Wasm 插件只能处理 HTTP header/body，不能改路由或熔断逻辑
有人想用 Go 写个 Wasm 插件来“动态决定走哪个集群”，这行不通。proxy-wasm-go-sdk 允许你在 onHttpRequestHeaders 或 onHttpResponse 阶段读写 header、修改 body、添加日志，但无法调用 router 或修改 cluster 选择结果——这些属于 Envoy Core 的调度逻辑，Wasm 沙箱无权触碰。
- 能做的：注入
X-Request-ID、根据User-Agent添加X-Envoy-Force-Trace、重写Locationheader - 不能做的：把
/api/v2/order请求重定向到cluster: order_v2_canary（这个必须靠 RouteConfiguration 的weighted_clusters或runtime_key控制） - Wasm 插件上线前必须用
wabt工具验证 WASM 字节码合规性，否则 Envoy 启动会报WASM runtime creation failed
Go 实现的轻量 Sidecar 代理 ≠ 替代 Envoy，而是补位场景
当你的服务只需要最简路由（比如所有 /health 打本地，其余打 upstream），又不想引入 Envoy 的复杂度和资源开销，才考虑用 Go 自研 Sidecar。但它和 Envoy 是互补关系，不是替代关系。
- Go Sidecar 适合：开发环境快速联调、IoT 边缘设备、函数计算冷启动场景下对延迟极度敏感的链路
- Envoy 仍不可替代：需要 TLS 终止 + mTLS 双向认证、gRPC 流控、HTTP/2 优先级树、连接池复用、健康检查主动探测等能力时
- 混用风险点：Go Sidecar 和 Envoy 同时监听 127.0.0.1:8080 会端口冲突；务必用
iptables或ip rule明确分流规则，别依赖 localhost 环回
真正容易被忽略的是 xDS 的响应顺序：Envoy 先加载 Cluster，再加载 RouteConfiguration，最后加载 Listener。如果你的 Go 控制平面并发推送三类资源，而没加版本号或依赖校验，Envoy 可能拿着旧 Cluster 去匹配新 Route，导致 503 或 404。这不是配置问题，是控制平面的状态同步缺陷。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
