绝大多数场景下无需用 Go 自研 Sidecar，Istio+Envoy 更稳妥；仅教学、轻量嵌入式网关、特定协议治理三类场景适合自研；需掌握 iptables 重定向、SO_ORIGINAL_DST 获取原始目的地址、独立 Prometheus 注册器、gRPC resolver/balancer 扩展等核心要点。
Go 语言写 Sidecar 代理，真要自己造轮子吗？
绝大多数场景下，不需要。Istio 默认用 Envoy（C++）做数据平面，不是因为 Go 不行，而是它已把 xDS 协议、TLS 握手、HTTP/2 流控这些边界情况打磨到极致。你自己用 net/http 或 gRPC-Go 写一个能跑通的代理很容易，但扛住高并发、连接突增、证书轮换、头部大小变化时，大概率会掉坑里。
真正适合用 Go 自研 Sidecar 的场景只有三个：教学演示、极轻量嵌入式网关（比如 IoT 边缘节点）、特定协议治理（如只处理 gRPC-Web 或自定义二进制协议）。其他情况，老老实实用 Istio + Envoy，再通过 EnvoyFilter 或 WASM 扩展行为更稳妥。
用 Go 拦截 HTTP 流量，iptables 和 SO_ORIGINAL_DST 是关键
Sidecar 要透明劫持流量，核心不是“转发”，而是“重定向”。Kubernetes 中 Istio 注入的 initContainer 就干这事：用 iptables 把进出 Pod 的 80/443 端口流量打到 Sidecar 监听的端口上。你如果自己写，必须理解 SO_ORIGINAL_DST 这个 socket 选项——它能让 Go 程序拿到原始目的地址（比如用户访问的是 service-b:8080，而不是 127.0.0.1:15001），否则服务发现和路由就全乱了。
- 别用
http.ReverseProxy直接转发，它默认丢掉原始 Host 和 X-Forwarded-For - 必须用
syscall.GetsockoptIPPacketInfo或第三方库（如github.com/containernetworking/plugins/pkg/ip/iputil）读取原始目标 IP - HTTPS 流量无法解密时，只能做 SNI 路由；想做 TLS 终止，得自己加载证书并 handle ALPN，复杂度陡增
指标上报和日志采集，别碰 Prometheus 的 /metrics 暴露逻辑
很多人一上来就学 Istio，在 Go Sidecar 里起一个 http.Server 暴露 /metrics，结果发现指标被反复 scrape 导致内存泄漏。根本原因是 prometheus/client_golang 的注册器默认是全局单例，多个 goroutine 并发写同一指标会 panic。
立即学习“go语言免费学习笔记（深入）”；
正确做法是：
- 用
prometheus.NewRegistry()创建独立注册器，避免污染主程序 - 所有指标变量（如
http_request_duration_seconds）必须在初始化时注册，不能每次请求都 NewVec - 日志别直接
fmt.Printf到 stdout，Sidecar 日志会被采集系统（如 Fluentd）按容器名+pod 标签分类，结构化字段（如method=GET,status=200）比纯文本好查十倍
gRPC 流量治理，优先用内置 balancer 和 resolver
Go 的 gRPC-Go 已经把服务发现、负载均衡、熔断的基础能力封装进 resolver 和 balancer 包里，不用自己 parse DNS SRV 或轮询 endpoints 列表。比如你要实现基于权重的灰度路由，只需实现一个自定义 balancer.Builder，在 Build 方法里根据服务标签（如 version:v2）过滤 resolver.Address 列表即可。
容易踩的坑：
-
grpc.WithBalancerName("round_robin")在 v1.60+ 已废弃，改用grpc.WithDefaultServiceConfig配置 JSON 字符串 - resolver 返回的
Address如果带Attributes字段（比如 metadata），必须深拷贝，否则并发修改会 panic - 不要在拦截器（
UnaryServerInterceptor）里做耗时操作（如调远程配置中心），gRPC 超时是端到端的，这里卡住整个 stream
Sidecar 最难的部分从来不是转发，而是怎么让业务无感地感知下游变化。比如服务实例下线后，连接池要不要立即驱逐？健康检查失败几次才标记为不健康？这些细节没压测过，上线就成事故点。
