Sidecar 是进程协作模式而非 Go 框架功能，需独立可执行、共享网络命名空间、通过 localhost/Unix socket 通信；Go 代理应专注协议转换与可观测性，避免 TLS 终止和 JWT 校验。
Sidecar 在 Go 中不是框架功能，而是进程协作模式
Go 本身不提供 sidecar 这类抽象，它只是个语言；所谓“Sidecar 模式”，本质是两个独立进程（主服务 + 辅助代理）共享网络命名空间（如 Docker 的 network_mode: "container:name"），由外部编排层（Kubernetes、Docker Compose）控制生命周期。你在 Go 里写的，只是一个能跑在容器里的、可被主应用“就近调用”的网络代理程序。
常见错误是试图用 os/exec 在主 Go 进程里启动另一个 Go 代理——这会导致信号转发失败、退出不同步、日志混杂，且违背 Sidecar “解耦但共存” 的设计本意。
- Sidecar 必须是独立可执行文件，和主服务镜像分离（哪怕同源编译）
- 必须通过
localhost或 Unix socket 与主服务通信，不能走 loopback 网络栈以外的路径 - Kubernetes 中需确保
shareProcessNamespace: true（仅调试需要），但生产环境更依赖initContainer和readinessProbe控制就绪顺序
用 net/http + httputil 实现轻量反向代理时绕不开的坑
很多 Go 开发者直接抄 httputil.NewSingleHostReverseProxy 示例，结果在线上遇到连接复用失败、header 丢失、超时不生效等问题。根本原因是默认配置没覆盖真实流量场景。
典型现象：502 Bad Gateway 频发、下游服务收到空 Content-Length、X-Forwarded-For 重复追加。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须显式设置
Director函数重写req.URL，否则路径透传会出错（比如主服务请求/api/v1/users，代理却发到http://upstream//api/v1/users） -
Transport要自定义：禁用 HTTP/2（某些上游不支持）、设置MaxIdleConnsPerHost（默认 2，高并发下成瓶颈）、启用IdleConnTimeout（防连接泄漏） - 手动清理/重写关键 header：
Connection、Keep-Alive、Proxy-Authenticate，否则可能触发中间设备拦截
proxy := httputil.NewSingleHostReverseProxy(upstreamURL)
proxy.Transport = &http.Transport{
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
ForceAttemptHTTP2: false,
}
proxy.Director = func(req *http.Request) {
req.URL.Scheme = upstreamURL.Scheme
req.URL.Host = upstreamURL.Host
req.Header.Set("X-Real-IP", realIP(req))
}Go 代理和主服务如何安全共享 localhost 网络
本地开发时用 localhost:8080 没问题，但容器内 localhost 指向的是当前容器自己的网络栈——这是最常踩的坑。Sidecar 和主服务必须运行在同一个网络命名空间，否则 localhost 不互通。
使用场景差异直接影响配置方式：
- Docker Compose：用
network_mode: "service:app"让代理容器共享主服务容器网络（注意：主服务容器名必须固定） - Kubernetes：Pod 内所有容器默认共享
localhost，但必须确保主服务和 Sidecar 容器都声明了ports，且readinessProbe检查的是代理的健康端点（如http://localhost:8081/healthz） - 本地调试：别用
go run启动代理，必须go build -o proxy ./cmd/proxy后用docker run --network=host或docker-compose启动，否则网络不可见
为什么不要在 Go Sidecar 里做 TLS 终止或 JWT 校验
这不是能力问题，而是职责越界。TLS 终止该由 Ingress（Nginx、Envoy）或 Service Mesh（Istio）统一处理；JWT 校验应下沉到 API 网关或主服务内部鉴权层。Go 编写的 Sidecar 只该做三件事：协议转换、流量镜像、简单路由、可观测性注入（如添加 X-Request-ID）。
一旦你在代理里加了 jwt.Parse 或 tls.Listen，就会引入以下问题：
- CPU 密集型操作阻塞事件循环，影响吞吐（Go 的
http.Server默认是单 goroutine 处理 TLS 握手） - 密钥管理失控：证书硬编码进二进制、私钥权限暴露、轮换需重启整个 Pod
- 可观测性断层：认证失败日志分散在 Sidecar，无法和主服务 trace 关联
真正该做的，是在代理中只透传 Authorization header，并把原始 client IP、scheme、host 注入 X-Forwarded-* 系列 header，让主服务自己决定怎么验。
