不适合——Envoy不应作为TLS终止点，而应以client/server身份参与mTLS双向认证；Golang服务需自行加载客户端证书并配置Transport或gRPC凭证，证书须由同一CA签发且Envoy validation_context须加载该CA根证书。
Envoy 作为 TLS 终止点是否适合 Golang 微服务间通信？
不适合直接用作服务间 TLS 终止点——这会破坏端到端加密语义，且增加证书管理复杂度。Golang 微服务间需要的是 mTLS（双向 TLS），而 Envoy 应当以 client 和 server 身份参与握手，而非终止 TLS。
典型错误是把 Envoy 配置成只做 HTTPS 入口代理，然后后端 Go 服务走明文 HTTP。这样外部流量加密了，内部服务调用仍是裸奔，不符合“透明流量加密”要求。
- 必须启用
tls_context并设置require_client_certificate: true实现双向认证 - Golang 服务需通过
http.Transport或grpc.DialOption使用客户端证书，不能依赖 Envoy 代签 - 证书必须由同一 CA 签发，且 Envoy 的
validation_context中要加载该 CA 的根证书（trusted_ca）
如何让 Golang HTTP 客户端自动携带证书而不改业务代码？
做不到完全“不改代码”，但可以最小化侵入：把证书加载和 Transport 构建抽离到初始化阶段，避免散落在每个 http.Client 创建处。
关键不是拦截请求，而是统一替换默认 Transport。Envoy 本身不参与证书分发，证书得由运维注入（如通过 volume mount），Go 服务启动时读取并构建带 mTLS 的 Transport。
立即学习“go语言免费学习笔记（深入）”；
- 用
http.DefaultTransport = &http.Transport{...}替换全局 Transport（注意并发安全） - 证书路径从环境变量读取，例如
os.Getenv("TLS_CERT_FILE")和os.Getenv("TLS_KEY_FILE") - 务必设置
TLSClientConfig.RootCAs加载 Envoy 提供的 CA 证书（通常挂载在/etc/ssl/certs/ca.pem） - 若用 gRPC，需传
grpc.WithTransportCredentials(credentials.NewTLS(...))，而非grpc.WithInsecure()
Envoy 的 cluster 配置里哪些字段决定 mTLS 是否生效？
仅靠 transport_socket 不够，必须同时满足三个条件，缺一不可：
-
transport_socket.name必须是envoy.transport_sockets.tls -
transport_socket.typed_config中的common_tls_context必须包含tls_certificates（客户端身份）和validation_context（服务端校验） - 对应 upstream cluster 的
tls_context.alpn_protocols要匹配后端 Go 服务实际协商的协议（如"h2"或"http/1.1"），否则连接会被静默拒绝
常见错误是漏配 validation_context，导致 Envoy 认为上游不可信，日志中出现 SSL error: SSLV3_ALERT_HANDSHAKE_FAILURE。
为什么 Go 服务健康检查总失败，而普通请求正常？
因为健康检查（如 /healthz）常被配置为不走 mTLS，但 Envoy 默认对所有 cluster 流量强制执行 transport socket。结果就是健康探针被 TLS 握手阻断。
- 解决方法：为健康检查单独建一个 cluster，禁用 TLS：
transport_socket: {}（空对象）或干脆不设transport_socket - 或者，在 Go 服务里让健康接口忽略 TLS 客户端证书验证（仅限内部网络，不推荐）
- Kubernetes livenessProbe 若用 httpGet，必须指向非 mTLS cluster 的端口，或改用 exec 探针
这个坑特别隐蔽——日志里没有明显报错，只是 probe 超时重启，容易误判为服务性能问题。
