必须用GetConfigForClient回调，因TLSConfig.Certificates启动后为只读快照，直接修改无效；该回调在每次握手时动态返回有效*tls.Config，支持热更新且不中断连接。
服务端证书热更新必须用 GetConfigForClient 回调
Go 的 http.Server 或 tls.Listener 启动后，TLSConfig.Certificates 字段是只读快照，直接改切片或重新赋值不会生效。想不中断连接换证书，唯一可靠路径是设置 TLSConfig.GetConfigForClient 回调函数，在每次 TLS 握手时动态返回当前有效的 *tls.Config 实例。
常见错误是试图在后台 goroutine 里轮询更新 TLSConfig.Certificates，结果新证书永远不被使用——因为 Go 运行时只在握手开始前调用一次该字段的拷贝逻辑。
-
GetConfigForClient必须返回非 nil 的*tls.Config，哪怕只是浅拷贝原配置 + 新证书 - 回调内应避免阻塞或长耗时操作（如读文件、解密），建议提前加载并缓存
tls.Certificate实例 - 若证书链含中间 CA，需确保
Certificate.Certificate字段包含完整 PEM 链（服务端证书 + 中间证书），否则客户端可能校验失败
证书加载失败会导致静默降级或握手失败
调用 tls.LoadX509KeyPair 失败时会返回空 tls.Certificate 和 error，但 GetConfigForClient 若返回空证书，Go 会直接拒绝握手，报错 remote error: tls: no certificate available。这不是 bug，而是安全设计：宁可断连，也不发空证书。
生产环境必须做防御性加载：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Stat检查证书/私钥文件是否存在且可读，再调用tls.LoadX509KeyPair - 私钥文件权限必须为
0600，否则 Go 会静默失败（尤其在容器中运行时容易忽略） - 证书过期不导致加载失败，但会在握手时触发
x509: certificate has expired；建议在加载后调用cert.Leaf.Verify做预检
多域名/泛域名场景下需匹配 ServerName
当一个服务托管多个域名（如 api.example.com 和 admin.example.com），且各自有独立证书时，不能靠 SNI 自动分发——GetConfigForClient 的 clientHelloInfo.ServerName 字段才是唯一可靠依据。
别假设客户端一定发 SNI：老设备或某些嵌入式客户端可能不带，此时 ServerName 为空字符串，需 fallback 到默认证书。
- 证书的
Leaf.DNSNames或Leaf.IPAddresses必须覆盖请求的ServerName，否则握手失败报x509: certificate is valid for xxx, not yyy - 泛域名证书（如
*.example.com）不匹配根域名example.com，需显式添加到DNSNames列表 - 若用私有 CA 签发，客户端信任链不变，但服务端证书的 SAN（Subject Alternative Name）仍需精确匹配
证书重载时机与原子性保障
证书轮换不是“换完就生效”，而是在下一次新连接握手时才生效。已建立的连接继续用旧证书加密，这是正确行为，也是 TLS 协议设计使然。
真正要防的是并发加载冲突：两个 goroutine 同时尝试更新内存中的证书变量，可能导致 GetConfigForClient 返回部分初始化的 tls.Certificate。
- 用
sync.RWMutex保护证书变量读写，写操作加写锁，GetConfigForClient内仅加读锁 - 不要在回调里做证书解析（如
x509.ParseCertificate），应在加载阶段完成并缓存*x509.Certificate实例 - 轮换日志必须记录证书序列号（
cert.Leaf.SerialNumber）和有效期，方便事后审计是否真的切到了新证
tls.Certificate 实例没重建，或者 GetConfigForClient 返回了零值 —— 这种失败不会 panic，只会让新连接直接断开。 
