tls.Config.GetCertificate必须使用，因为它在每次TLS握手时根据SNI动态返回匹配证书，支持多域名、通配符匹配和热更新；直接配置Certificates字段仅启动时生效，无法应对SNI路由或证书轮换，会导致域名不匹配错误或服务中断。
tls.Config.GetCertificate 为什么必须用，而不是直接配 Certificates
因为单个 Certificates 字段只能固定返回一个证书，无法应对多域名、SNI 路由或证书轮换等场景。浏览器或客户端在 TLS 握手初期会通过 SNI（Server Name Indication）发送目标域名，GetCertificate 回调正是在这个阶段被调用，让你有机会根据 ClientHelloInfo.ServerName 动态选证。
常见错误现象：配置了多个域名（如 api.example.com 和 www.example.com），但只传了一个证书，结果访问另一个域名时出现 x509: certificate is valid for ... not ...；或者证书过期后硬重启服务，造成短暂中断。
-
GetCertificate函数签名是func(*tls.ClientHelloInfo) (*tls.Certificate, error)，必须返回非 nil 的*tls.Certificate或明确 error（比如域名不支持） - 若回调 panic 或返回 nil，Go 会静默关闭连接，日志里只显示
accept tcp: use of closed network connection，非常难排查 - 证书必须已预加载进内存（例如用
tls.LoadX509KeyPair提前解析），不能在回调里反复读文件——I/O 延迟和并发竞争会导致握手超时
如何安全缓存并复用 tls.Certificate 对象
每次 TLS 握手都重新调用 tls.LoadX509KeyPair 不仅慢，还可能因文件锁或路径变动失败。正确做法是启动时一次性加载，按域名索引存入 map，并保证线程安全。
典型结构：
var certMap sync.Map // key: string (domain), value: *tls.Certificate
// 启动时加载
for _, cfg := range []struct{ domain, certFile, keyFile string }{
{"api.example.com", "api.crt", "api.key"},
{"www.example.com", "www.crt", "www.key"},
} {
cert, err := tls.LoadX509KeyPair(cfg.certFile, cfg.keyFile)
if err != nil {
log.Fatal("failed to load cert for", cfg.domain, err)
}
certMap.Store(cfg.domain, &cert)
}
- 不要用普通
map[string]*tls.Certificate+sync.RWMutex，sync.Map更适合读多写少的证书缓存场景 - 证书加载失败必须提前暴露（比如
log.Fatal），否则运行中首次访问该域名才会 panic，服务已上线却不可用 - 如果证书含中间 CA，确保
certFile是拼接好的 PEM（leaf → intermediate），否则客户端（尤其是 iOS/macOS）可能校验失败
GetCertificate 回调里怎么处理通配符和默认证书
不是所有请求都带有效 ServerName：HTTP/1.1 直连、curl 不加 -H "Host:"、旧客户端或 IP 直连时，ClientHelloInfo.ServerName 可能为空或非法。这时候需要 fallback 逻辑。
- 先查精确匹配：
certMap.Load(domain) - 再查通配符（如
*.example.com）：需手动字符串匹配，Go 标准库不内置通配符解析；推荐用strings.HasSuffix(domain, ".example.com") && len(domain) > len(".example.com") - 最后 fallback 到默认证书（如
default.crt）：避免返回 nil 导致握手失败，但注意这个证书的 SAN 必须包含空字符串或通用名，否则仍可能报错 - 绝对不要在回调里做阻塞操作（如 HTTP 请求、数据库查询），TLS 握手超时通常只有几秒，超时后连接直接断开
为什么 GetCertificate 返回的证书必须包含完整链，且不能加密私钥
Go 的 crypto/tls 在握手时直接使用返回的 *tls.Certificate 中的 Certificate（[][]byte）和 PrivateKey（crypto.PrivateKey）字段。任何格式或内容偏差都会导致握手失败。
- 私钥必须是未加密 PEM 格式：以
-----BEGIN RSA PRIVATE KEY-----或-----BEGIN EC PRIVATE KEY-----开头；带密码的-----BEGIN ENCRYPTED PRIVATE KEY-----会被tls.LoadX509KeyPair拒绝，报tls: failed to parse private key - 证书切片
Certificate至少含一个元素（终端证书），若需中间证书，必须按顺序追加：终端证书在前，根证书在后；顺序反了或漏掉中间证书，某些客户端（如 Java HttpClient）会校验失败 - 证书的
Subject.CommonName或DNSNames（SAN）必须覆盖请求的ServerName，否则即使选对了证书，也会在后续验证阶段失败
最易忽略的一点：证书有效期和密钥强度本身不会在 GetCertificate 阶段校验，但一旦过期或使用已被淘汰的 SHA-1 签名，客户端会在握手完成后立即断开，并报模糊错误如 remote error: tls: bad certificate —— 此时要抓包看 Alert 内容，不能只盯着 Go 日志。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
