必须使用mTLS而非单向TLS，因其强制双向证书验证以防止服务冒充；Go服务端需正确配置tls.Config的ClientCAs和ClientAuth，客户端须自定义Transport并加载证书及根CA。
Go 微服务之间默认走明文 HTTP，不加防护直接暴露在内网或 Kubernetes Pod 网络中，等于把服务接口裸奔——哪怕只在内网，也存在中间人、节点逃逸、配置误漏等现实风险。必须加密通信，而最务实的做法是用 TLS 双向认证（mTLS），不是靠自研加解密或 JWT 透传做“假安全”。
为什么必须用 mTLS 而不是只加 HTTPS 单向证书
单向 TLS（服务端有证书，客户端不验）只能防窃听，不能防冒充。攻击者只要拿到服务地址，就能伪造请求调用你的订单服务、用户服务。mTLS 强制双方交换并验证证书，确保只有持有合法客户端证书的服务才能接入——这才是微服务间“身份可信”的基础。
-
http.DefaultTransport默认不校验服务端证书，容易被中间人劫持；必须显式配置tls.Config并启用InsecureSkipVerify: false - 客户端证书需由同一 CA 签发，服务端通过
ClientCAs和ClientAuth: tls.RequireAndVerifyClientCert强制校验 - Kubernetes 中若用 Istio，它默认注入的 sidecar 已支持 mTLS，但 Go 服务自身仍需正确加载证书，否则
http.Client会因无证书被服务端拒绝
Go 服务端启用 mTLS 的关键配置点
标准 http.Server 不自带证书校验逻辑，必须手动构造 tls.Config 并传入 ListenAndServeTLS。漏掉任一环节都会导致连接被拒或降级为单向。
- 服务端证书和私钥必须用 PEM 格式，路径需可读：
server.crt、server.key - CA 证书（用于验证客户端）必须加载进
ClientCAs字段，且类型是*x509.CertPool，不能直接传文件路径 -
ClientAuth必须设为tls.RequireAndVerifyClientCert，设成tls.VerifyClientCertIfGiven会导致未带证书的请求静默通过 - 若用自签名 CA，客户端必须信任该 CA，否则
x509: certificate signed by unknown authority错误无法绕过
cert, _ := tls.LoadX509KeyPair("server.crt", "server.key")
caCert, _ := ioutil.ReadFile("ca.crt")
caPool := x509.NewCertPool()
caPool.AppendCertsFromPEM(caCert)
srv := &http.Server{
Addr: ":8443",
TLSConfig: &tls.Config{
Certificates: []tls.Certificate{cert},
ClientCAs: caPool,
ClientAuth: tls.RequireAndVerifyClientCert,
},
}
srv.ListenAndServeTLS("", "")
Go 客户端发起 mTLS 请求的常见错误
很多团队只配了服务端，客户端仍用默认 http.Client，结果报错 tls: failed to verify certificate: x509: certificate signed by unknown authority 或更隐蔽的 remote error: tls: bad certificate——后者往往是因为客户端没发证书，但服务端又强制要求。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须创建自定义
http.Transport，设置TLSClientConfig，不能只改http.Client.Timeout -
Certificates字段要传[]tls.Certificate，需用tls.LoadX509KeyPair("client.crt", "client.key")加载，不能只传公钥 - 若服务端 CA 与客户端根 CA 不同，必须在
TLSClientConfig.RootCAs中显式加载服务端 CA，否则校验失败 - 使用
http.DefaultClient时，其底层Transport是共享的，修改会影响其他请求；应新建独立http.Client
cert, _ := tls.LoadX509KeyPair("client.crt", "client.key")
caCert, _ := ioutil.ReadFile("server-ca.crt")
rootPool := x509.NewCertPool()
rootPool.AppendCertsFromPEM(caCert)
tr := &http.Transport{
TLSClientConfig: &tls.Config{
Certificates: []tls.Certificate{cert},
RootCAs: rootPool,
},
}
client := &http.Client{Transport: tr}
resp, _ := client.Get("https://service-b:8443/health")
证书轮换时最容易被忽略的细节
证书过期是生产环境最常导致服务雪崩的安全事件之一。Go 程序不会自动重载证书文件，重启服务是下策，热更新才是可行路径。
-
tls.Config.GetCertificate回调函数可用于动态提供证书，但需自行实现文件监听+解析逻辑 - 不要在每次请求中重新
LoadX509KeyPair，开销大且易出错；应缓存证书并原子替换tls.Config.Certificates字段 - 证书更新后，旧连接仍可用，但新连接会用新证书；若用连接池，需考虑
IdleConnTimeout配合 graceful shutdown - Kubernetes 中若用 cert-manager，建议配合
volumeMounts挂载 Secret，并用 inotify 监听文件变化，而非轮询
证书路径硬编码、不验证证书有效期、跳过客户端校验、复用未隔离的 Transport——这些看似省事的操作，在真实故障面前毫无容错余地。
