双向TLS认证的核心是服务端必须设tls.Config.ClientAuth为tls.RequireAndVerifyClientCert且客户端必须显式加载并提供有效证书，任一缺失均导致静默降级或握手失败。
双向TLS认证的核心判断：服务端必须设置 ClientAuth 且客户端必须提供有效证书
Go 的 crypto/tls 默认只做服务端认证（即客户端验证服务器证书），要实现双向认证，关键不是“多加几行代码”，而是服务端明确要求客户端证书，并且客户端在发起连接时主动携带。漏掉任一端的配置，都会静默降级为单向 TLS，甚至直接握手失败。
tls.Config 中 ClientAuth 的取值差异直接影响行为
服务端 tls.Config 的 ClientAuth 字段决定是否校验、如何校验客户端证书。常见误用是设成 tls.RequireAnyClientCert —— 它只要求有证书，但不校验签名或有效期，形同虚设；生产环境必须用 tls.RequireAndVerifyClientCert。
-
tls.NoClientCert：不请求客户端证书（默认值） -
tls.RequestClientCert：发送证书请求，但不强制提供；客户端可忽略 -
tls.RequireAnyClientCert：客户端必须提供证书，但不验证其有效性（不推荐） -
tls.VerifyClientCertIfGiven：有证书则验证，无则跳过（适合灰度场景） -
tls.RequireAndVerifyClientCert：必须提供且必须通过验证（生产首选）
客户端必须显式加载 Certificates 并传入 tls.Config
很多开发者以为只要服务端开了双向认证，客户端就会自动用系统证书，这是错的。Go 的 http.Client 或 tls.Dial 不会自动读取系统证书库，客户端必须自己解析 .pem 或 .crt + .key 文件，构造成 tls.Certificate 并注入 tls.Config.Certificates。
典型错误写法：http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{} —— 这里没设 Certificates，连接会因 “no client certificate” 被服务端拒绝，错误信息通常是 remote error: tls: bad certificate 或更模糊的 i/o timeout（因握手卡在证书交换阶段）。
正确做法示例：
cert, err := tls.LoadX509KeyPair("client.crt", "client.key")
if err != nil {
log.Fatal(err)
}
conf := &tls.Config{
Certificates: []tls.Certificate{cert},
RootCAs: certPool, // 验证服务端证书用
}
CA 证书池（RootCAs 和 ClientCAs）不能混用
服务端需要 ClientCAs 来验证客户端证书签名，客户端需要 RootCAs 来验证服务端证书。两者都用 x509.NewCertPool() 创建，但内容完全独立：前者加载的是签发客户端证书的 CA 公钥（如 ca.crt），后者加载的是签发服务端证书的 CA 公钥（可能是同一个文件，也可能不同）。把服务端的 ca.crt 错误塞进客户端的 ClientCAs，会导致客户端证书无法被识别。
容易被忽略的一点：服务端的 ClientCAs 必须包含客户端证书的**直接签发者**，如果客户端证书是中间 CA 签发的，而 ClientCAs 只加载了根 CA，且中间 CA 证书未随客户端证书一起发送（即未在 tls.LoadX509KeyPair 的 crt 文件中拼接中间证书），验证就会失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
