推荐基于golang.org/x/net/proxy+net/http/httputil搭建反向代理骨架，gRPC流量用grpc.Dial配合自定义resolver.Builder，HTTP出向连接加context.WithTimeout，xDS通信用envoyproxy/go-control-plane并正确订阅三类资源，iptables规则需分步注入并验证，Go sidecar需设GOMEMLIMIT和限流防护。
Sidecar 代理该用什么 Go 库做基础网络层
Go 原生 net/http 和 net 包够用，但直接裸写 HTTP/2、TLS 终止、gRPC 透传会重复造轮子。实际项目里更推荐基于 golang.org/x/net/proxy + net/http/httputil 搭建反向代理骨架，再用 google.golang.org/grpc 的 grpc.WithContextDialer 控制下游连接。
别碰 gorilla/handlers 这类老库——它对 HTTP/2 流控支持弱，容易在长连接场景下丢 header；也别默认启用 http.Transport.MaxIdleConnsPerHost = 0，这会让 sidecar 在高并发时疯狂建新连接，压垮上游服务。
- HTTP 流量走
httputil.NewSingleHostReverseProxy，但必须重写Director函数，否则 Host 头不会更新 - gRPC 流量必须用
grpc.Dial配合自定义resolver.Builder，否则无法做服务发现路由 - 所有出向连接建议加
context.WithTimeout，sidecar 本身不处理业务逻辑，超时不传递是底线
Envoy 控制平面通信：xDS 协议怎么连上 Istio Pilot
Go 侧不需要实现完整 xDS，用 github.com/envoyproxy/go-control-plane 就行，重点是配置好 cache.SnapshotCache 和 server.NewServer 的生命周期。常见错误是没设 cache.SetSnapshot 后忘记调 cache.ClearWatch，导致 Pilot 一直重推旧配置。
注意 Istio 1.17+ 默认用 ADS（Aggregated Discovery Service），你的 sidecar 必须同时订阅 ClusterLoadAssignment、Listener、RouteConfiguration 三类资源，缺一个就会卡在 “waiting for CDS” 状态。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 证书路径必须指向 Istio 注入的
/var/run/secrets/istio/root-cert.pem，硬编码或 fallback 到系统 CA 会握手失败 - 连接 Pilot 的地址不是
istiod.istio-system.svc，而是通过环境变量ISTIO_META_XDS_HOST获取，否则多集群场景下会连错 - 每次
SetSnapshot后要主动调cache.IncrementalUpdate，否则 Pilot 不知道你已收到
流量劫持失败时怎么看 iptables 规则是否生效
Go 侧代码再正确，如果 iptables -t nat -L -n -v 里没有对应 REDIRECT 或 TPROXY 规则，流量根本到不了你的程序。Kubernetes Init Container 注入规则时最常踩的坑是没指定 --match-set 的 ipset 名称，或者用 iptables-legacy 而非 iptables-nft 导致规则不兼容。
验证方法很简单：进容器执行 iptables -t nat -S | grep -E "(REDIRECT|TPROXY)"，看目标端口是否匹配你 sidecar 监听的 15001（inbound）和 15006（outbound）；再用 ss -tlnp | grep :1500 确认 Go 进程确实在监听。
- 如果规则存在但流量没进来，大概率是 Pod 的
net.ipv4.conf.all.route_localnet=0，需在 init container 里设为 1 - IPv6 场景下必须显式加
-t mangle表规则，nat表默认不处理 v6 - 不要依赖
iptables-restore脚本一次性加载——Istio 的规则有顺序依赖，得按PREROUTING → OUTPUT → POSTROUTING分步插
Go sidecar 如何避免被 Kubernetes OOMKilled
Go 程序默认内存行为在容器里很危险：runtime.GC 不会主动归还内存给 OS，而 K8s 的 memory.limit 是硬限制。一旦 sidecar 缓存了大量 TLS session 或 HTTP body，很容易触发 OOMKilled。
关键动作就两个：启动时设 GOMEMLIMIT（Go 1.19+），并在 HTTP handler 里用 http.MaxBytesReader 限请求体大小。别信 “Go 自动管理内存” —— 容器里没有 swap，超限就是杀进程。
-
GOMEMLIMIT建议设为容器 limit 的 80%，比如 limit 是 512Mi，就设GOMEMLIMIT=429496729（字节） - 所有
io.Copy操作前加io.LimitReader，否则大文件上传会吃光内存 - 禁用
http.Transport.IdleConnTimeout = 0，保持连接池大小可控，否则空闲连接堆积也会涨 RSS
Sidecar 的复杂性不在协议实现，而在它必须同时活在三个边界上：内核网络栈、Kubernetes 调度约束、控制平面的动态配置节奏。任何一个边界出偏差，表现出来的都是“流量突然不通”或者“Pod 反复重启”，而不是清晰的 error log。
