crypto/tls 支持双向 TLS（mTLS），服务端需设 ClientAuth: tls.RequireAndVerifyClientCert 与 ClientCAs，客户端需配 RootCAs；gRPC 需用 credentials.NewTLS 注入凭证；证书须完整、无密码、含正确 SAN；生产环境禁用自签名，CA 证书应预解析并挂载为 Secret。
用 crypto/tls 配置双向 TLS（mTLS）是最直接的方案
Go 标准库的 crypto/tls 完全支持服务端和客户端证书校验，不需要第三方库。关键不是“加不加密”，而是“谁来认证谁”——单向 TLS（仅服务端证书）防窃听但不防冒充；双向 TLS 才能确保调用方是可信服务。
常见错误现象：tls: failed to verify certificate: x509: certificate signed by unknown authority，本质是客户端没加载 CA 证书或服务端没开启 ClientAuth: tls.RequireAndVerifyClientCert。
- 服务端必须显式设置
tls.Config{ClientAuth: tls.RequireAndVerifyClientCert, ClientCAs: caPool} - 客户端发起连接前，需用
tls.Dial并传入含服务端 CA 的tls.Config{RootCAs: caPool} - 证书链要完整：服务端证书 + 中间 CA（如有）+ 根 CA；私钥必须是 PEM 格式且无密码保护（Go 不支持解密带密码的 key 文件）
gRPC 场景下用 credentials.TransportCredentials 替换默认连接
gRPC-Go 默认走明文 HTTP/2，必须手动注入 TLS 凭据。不是改 handler 或中间件，而是替换底层连接工厂。
使用场景：两个微服务通过 gRPC 通信，如 user-service 调 order-service，双方都需验证对方身份。
立即学习“go语言免费学习笔记（深入）”；
- 服务端启动时：用
grpc.Creds(credentials.NewTLS(serverTLSConfig))注册监听 - 客户端 Dial 时：同样传入
grpc.WithTransportCredentials(credentials.NewTLS(clientTLSConfig)) - 注意
serverTLSConfig和clientTLSConfig的ClientAuth和RootCAs字段必须配对——服务端校验客户端证书，客户端校验服务端证书
serverTLSConfig := &tls.Config{
Certificates: []tls.Certificate{cert},
ClientAuth: tls.RequireAndVerifyClientCert,
ClientCAs: caPool,
}
证书轮换时避免服务中断的关键操作
证书过期会导致整个服务不可用，但 Go 的 http.Server 和 grpc.Server 都不支持热更新证书。必须自己实现 reload 逻辑。
容易踩的坑：直接重载 tls.Config 字段会引发竞态，或新旧证书切换间隙出现连接拒绝。
- 用
sync.RWMutex包裹*tls.Config指针，所有连接都读取该指针值 - 轮换时生成新
tls.Config，原子替换指针，再调用srv.Close()+srv.Serve(lis)重启监听（非优雅） - 更稳妥的做法：启动新 listener 监听新端口，健康检查通过后切流量，再停旧 listener（适合有负载均衡器的环境）
不要用自签名证书做生产环境的 mTLS
自签名证书在开发阶段方便，但一旦部署到 Kubernetes 或 Consul 等平台，会和内置 CA 冲突，且无法被外部审计工具识别。真实环境必须用私有 CA 签发。
性能影响常被忽略：每次 TLS 握手都会触发证书链验证，如果 ClientCAs 加载的是未解析的 PEM 文件（而非已调用 caPool.AppendCertsFromPEM() 的 *x509.CertPool），会导致每次连接都重复解析，CPU 毛刺明显。
- 务必提前调用
caPool.AppendCertsFromPEM(pemBytes)，缓存解析结果 - 私有 CA 的根证书应单独分发，不随服务镜像打包；建议挂载为 Kubernetes
Secret卷 - 证书中
Subject Alternative Name (SAN)必须包含服务 DNS 名（如order-service.default.svc.cluster.local），否则客户端校验失败
