sidecar不是go语言特性，而是kubernetes中同pod多容器的部署形态；go服务须监听0.0.0.0、显式设http客户端超时、主动探测sidecar健康端点，并适配unix socket或http/2/tls协议兼容性。
Go 微服务里没有“内置的 Sidecar 模式”，它不是语言特性，而是部署形态——Sidecar 必须是独立进程，和 Go 主服务共 Pod、共享网络命名空间，靠 localhost 通信。Service Mesh 的本质，是把 Sidecar 集群化 + 控制面集中化，不是给 Go 加新语法。
Sidecar 不是 Go 的库或函数，而是独立可执行文件
很多人在 main.go 里写 exec.Command("./sidecar") 启动代理，这是典型错误：主进程一崩，sidecar 可能还在跑；sidecar 崩了，Go 服务毫无感知。Sidecar 必须和主服务平级部署：
- Kubernetes 中：同个
Pod下两个容器，用initContainers或livenessProbe协调启动顺序 - Docker Compose 中：用
network_mode: "service:app"共享网络栈 - 本地调试时：手动启动
envoy或自研代理二进制，监听127.0.0.1:15001，Go 服务只连这个地址
Go 服务怎么安全连 localhost 上的 Sidecar？
Sidecar 启动慢、健康检查未就绪、端口被占，都会让 Go 的 http.Client 直接卡死或返回 dial tcp 127.0.0.1:15001: connect: connection refused。不能依赖默认超时（可能 30 秒），也不能在 init() 里探测：
- 显式设置
http.Client.Timeout，比如5 * time.Second - 启动后主动探测 Sidecar 健康端点，例如
http://localhost:15021/healthz/ready，最多重试 3 次，每次间隔 1 秒 - 若 Sidecar 用 Unix Socket（如
unix:///var/run/sidecar.sock），Go 必须用http.Transport.DialContext替换默认拨号逻辑，否则报connection refused
Envoy + Go 常见静默失败场景
Envoy 默认启用 HTTP/2，但 Go 的 http.Client 在非 TLS 场景下不协商 HTTP/2；如果 Envoy 强制 h2 并禁用 http/1.1，请求会直接被拒绝，日志里只显示延迟飙升或 503 Service Unavailable：
- 检查 Envoy 监听器配置中是否设置了
force_http1: true - Go 侧若需 HTTP/2，必须走 TLS（哪怕自签证书），且
http.Client.Transport要启用TLSClientConfig - 用
curl -v http://localhost:15001/healthz和ss -tlnp | grep :15001确认底层连通性，别只信日志
Sidecar 的复杂点不在代码，而在生命周期对齐和协议兼容性——Go 服务永远不该知道 Sidecar 是 Envoy 还是自研代理，但它必须容忍 Sidecar 启动延迟、重启抖动、协议降级这些现实问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
