必须显式设置tls.RequireAndVerifyClientCert，否则服务端仅执行单向TLS且完全忽略客户端证书；常见错误是使用tls.VerifyClientCertIfGiven或未设置ClientAuth字段（默认tls.NoClientCert），均不满足强制双向要求。
tls.RequireAndVerifyClientCert 必须显式设置
不设这个，服务端就只做单向 TLS，客户端证书压根不会被读取或校验。很多团队反复检查证书格式、路径、权限，最后发现只是漏了这一行。
常见错误配置：tls.VerifyClientCertIfGiven 或干脆不设 ClientAuth 字段（默认是 tls.NoClientCert）。前者允许无证书连接，后者直接跳过，都不满足双向强制要求。
-
TLSConfig.ClientAuth必须显式赋值为tls.RequireAndVerifyClientCert -
TLSConfig.ClientCAs要加载 CA 根证书池（*x509.CertPool），不是客户端的 cert.pem - 服务端自己的证书和私钥走
http.ListenAndServeTLS(certFile, keyFile)，和ClientCAs完全无关 - 若用
net/http.Server，记得把完整TLSConfig挂到srv.TLSConfig，再调srv.ListenAndServeTLS("", "")
x509: certificate signed by unknown authority 怎么定位
这不是证书“坏了”，而是信任链断了。错误本质永远是：服务端不信任客户端的签发者，或客户端不信任服务端的签发者。
排查顺序不能乱：
- 先确认服务端
ClientCAs是否加载了签发客户端证书的那个 CA 根证书 - 再确认客户端
tls.Config.RootCAs是否加载了签发服务端证书的那个 CA 根证书（不是服务端的cert.pem） - 客户端自己的证书链必须完整：如果用了中间 CA，
Certificates[0].Certificate要包含终端证书 + 中间证书，不能只放终端证书
快速验证命令：openssl s_client -connect host:port -cert client.crt -key client.key -CAfile ca.crt，能通说明组合没问题。
InsecureSkipVerify = true 为什么有时还是报错
Go 1.19+ 加了限制：即使开了 InsecureSkipVerify，只要 ServerName 设置了且和证书 Subject Alternative Name 不匹配，TLS 握手仍会失败。
- 检查
tls.Config.ServerName是否为空——http.Client默认会把 URL Host 填进去，若服务端证书没覆盖该域名，跳过也白搭 - 某些环境（如 Istio mTLS）会在 TCP 层拦截，根本到不了 TLS 握手阶段；此时看错误是
tls: first record does not look like a TLS handshake而非 x509 类 - 真要绕过过期但保留其他校验，得接管
VerifyPeerCertificate，只忽略NotAfter时间检查，其余逻辑照常走
http.Transport 连接复用失效的隐性原因
mTLS 下，每个客户端证书不同，http.Transport 的连接复用哈希键包含整个 tls.Config 实例。若每次请求都 new 一个带不同 Certificates 的 config，哈希值总变，连接永远无法复用。
典型表现是 QPS 上不去、TIME_WAIT 爆增、CPU 持续偏高。
- 不要在每次请求时动态构造新
tls.Config；应复用 transport 实例，按需切换证书（比如用GetClientCertificate回调） - 若必须多证书，考虑按证书分组维护多个 transport，而不是每次都重建
- 注意
RootCAs和Certificates都参与哈希计算，哪怕只改其中一个字段也会导致复用失效
最易被忽略的是：证书链完整性、ServerName 匹配、以及 transport 复用与证书生命周期的耦合关系——这三处出问题，日志里往往只显示“connection refused”或“timeout”，根本看不出是 TLS 配置动了手脚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
