envoy 官方不支持 go 插件，go-control-plane 仅用于生成 xds 配置；go 扩展需通过 wasm（需 tinygo 编译）或 grpc service（独立进程、有延迟和序列化开销）实现。
Envoy 的 Go 插件支持其实不存在
Envoy 本身是用 C++ 写的，官方不支持 Go 编写的过滤器或插件。你看到的 go-control-plane 只是生成 xDS 配置的 SDK，不是运行时插件机制。想用 Go 扩展 Envoy 的核心逻辑（比如修改请求头、鉴权、路由决策），必须走 WASM 或 gRPC Service 方式——但这两者都不是“写个 Go 函数就热加载”的体验。
常见错误现象：undefined symbol: _GoStringPtr 或插件编译通过却在 Envoy 启动时报 WASM runtime initialization failed，本质是混淆了配置生成和运行时扩展。
- WASM 方式需用 TinyGo 编译，标准 Go 运行时（含 goroutine、GC、net/http）无法打包进 WASM
- gRPC Service 是独立进程，通过 Unix Domain Socket 或 TCP 与 Envoy 通信，延迟高、运维多一跳
- 所有 Go 实现都绕不开序列化开销：Envoy 把
HttpRequest序列化成 Protobuf，你的 Go 服务反序列化后再处理，再序列化回 Envoy —— 不适合低延迟敏感场景
Kong 的 Go Plugin 没有原生支持
Kong 官方插件生态基于 Lua（OpenResty），其 kong-plugin 规范只认 Lua 文件。所谓“Go 插件”，实际是用 go-resty 或 net/http 起一个独立 HTTP 服务，再在 Kong 的 http-log 或 proxy-rewrite 阶段用 http://localhost:8081/validate 调用它——这本质上是个外部服务集成，不是插件。
使用场景有限：适合做异步审计日志、离线风控回调；不适合同步鉴权或 header 改写，因为会引入额外 RTT 和失败降级问题。
立即学习“go语言免费学习笔记（深入）”；
- 若用
pre-function或access阶段调 Go 服务，Kong 默认超时是 60s，但真实业务常需控制在 50ms 内，必须显式配config.timeout - Go 服务挂了，Kong 默认行为是 500 错误，无法 fallback 到本地缓存或默认策略，得自己加 circuit breaker
- Kong 3.x+ 的 DB-less 模式下，没法动态 reload Go 服务配置，每次改都要重启 Go 进程
真正在 Go 中可控的网关：从零写一个轻量 proxy
如果你的核心诉求是“用 Go 写、能 debug、能单元测试、能嵌入现有 infra”，直接基于 net/http + httputil.NewSingleHostReverseProxy 构建更现实。它不替代 Envoy/Kong 的全功能，但对中小规模路由、Header 注入、JWT 解析、灰度分流等场景足够轻快。
性能影响小：Go 原生 HTTP server 处理 10k QPS 无压力，比 WASM 或跨进程调用低两个数量级延迟；兼容性好：可复用 context.Context、http.Transport 超时、TLS 配置等成熟能力。
- 别碰
http.DefaultTransport：它共享连接池且无超时，务必自定义&http.Transport{IdleConnTimeout: 30 * time.Second} - 转发前修改 request：用
req.Header.Set("X-Forwarded-For", ...)，但注意req.Host和req.URL.Host要同步，否则后端看到空 host - 需要 TLS 终止？直接用
http.Server.TLSConfig，别套 Nginx；需要 SNI 路由？用tls.Config.GetConfigForClient动态返回*tls.Config
扩展点设计比语言选择更重要
真正卡住落地的，从来不是“该选 Envoy 还是 Kong”，而是扩展点是否匹配你的变更节奏。比如灰度发布要按 Header 灰度，但 Kong 的 request-transformer 不支持正则提取值，就得自己写 Lua；而 Go proxy 里一行 re.FindStringSubmatch(req.Header["X-Env"]) 就搞定。
容易被忽略的复杂点：状态同步。Envoy 的 xDS 是最终一致，Kong 的 DB 是强一致但慢；而你手写的 Go proxy 若要做多实例配置热更新，得自己接 etcd Watch 或 redis pub/sub，这部分工作量常被低估。
