Go 服务间认证核心是证书生命周期管理、身份验证和流量加密，生产环境首选 mTLS；需正确配置 crypto/tls 的 ClientAuth、Certificates 和 RootCAs，禁用 InsecureSkipVerify 仅限测试，避免 JWT/API Key 主认证，证书管理须依赖 cert-manager 或 Vault 并实现热重载。
Go 服务间认证的核心不是“选哪种方案”，而是“谁控制证书生命周期、谁验证身份、流量是否加密”。TLS 双向认证（mTLS）是生产环境最直接、最可控的起点。
用 crypto/tls 配置 mTLS 客户端和服务端
Go 标准库 原生支持 mTLS，无需额外框架。关键在证书加载和 tls.Config 设置是否匹配。
- 服务端必须设置
ClientAuth: tls.RequireAndVerifyClientCert，否则不强制验客户端证书 - 客户端必须显式加载
tls.Certificate（含私钥 + 证书链），不能只传 CA 根证书 - 双方共用的 CA 证书必须一致；服务端的
ClientCAs和客户端的RootCAs都要加载同一份 CA PEM - 若用自签名 CA，客户端调用时需禁用默认证书校验（
InsecureSkipVerify: true），但仅限测试 —— 正式环境必须通过RootCAs显式信任
srv := &http.Server{Addr: ":8443", TLSConfig: &tls.Config{ ClientAuth: tls.RequireAndVerifyClientCert, ClientCAs: caPool, // *x509.CertPool，含 CA 根证书}, } http.ListenAndServeTLS(":8443", "server.crt", "server.key", nil)用 net/http 发起带客户端证书的请求
HTTP 客户端必须使用自定义 http.Transport，否则证书不会被发送。
-
http.DefaultTransport不支持客户端证书，硬 编码 跳过 TLS 配置 - 必须新建
http.Transport并设置TLSClientConfig，其中Certificates是[]tls.Certificate - 若服务端证书非公网可验证（如内网域名、IP 地址），需在
TLSClientConfig中设置ServerName或自定义VerifyPeerCertificate
cert, _ := tls.LoadX509KeyPair("client.crt", "client.key") tr := &http.Transport{TLSClientConfig: &tls.Config{ Certificates: []tls.Certificate{cert}, RootCAs: caPool, ServerName: "api.internal", // 匹配服务端证书的 CN 或 SAN }, } client := &http.Client{Transport: tr} resp, _ := client.Get("https://api.internal:8443/health")避免用 JWT 或 API Key 做服务间主认证
JWT 在服务间调用中容易引入密钥分发、轮换、时钟偏移、签名算法降级等运维负担；API Key 更是明文传输风险高、无绑定信道、无法吊销。
立即学习“go 语言免费学习笔记（深入）”；
- mTLS 天然绑定 TCP 连接，证书私钥不出内存，通信即认证，无需额外 token 解析逻辑
- JWT 适合用户会话或 跨域 授权，不适合高频、低延迟、强信任的服务网格内部通信
- 若必须用 JWT（如对接遗留系统），务必用 mTLS 通道传输，并校验
iss、aud、exp和签名公钥（而非共享密钥）
证书生命周期管理是最大落地难点
Go 本身不提供证书签发、续期、吊销功能。实际运行中，证书过期或私钥泄露会导致整个服务调用链中断。
- 不要手动生成长期证书；应接入 cert-manager（K8s）或 HashiCorp Vault PKI 引擎
- 证书加载不能写死路径；建议用
fsnotify监听文件变化后热重载tls.Config - 服务启动时应校验证书有效期（
leaf.NotBefore/NotAfter），避免静默失败 - 日志中记录证书指纹（
leaf.SignatureSHA256）便于审计，但别打私钥
真正卡住团队的往往不是代码怎么写，而是谁生成证书、谁分发、谁监控过期、出问题时怎么快速替换 —— 这些必须在设计阶段明确职责，而不是堆砌 Go 的 tls 调用。
