Go中启用TLS双向认证必须将tls.Config.ClientAuth设为tls.RequireAndVerifyClientCert，否则即使配置ClientCAs也会静默降级为单向；需确保ClientCAs非空且正确加载，客户端须同时提供Certificates和RootCAs。
tls.Config.ClientAuth 设为 tls.NoClientCert 就是跳过客户端证书验证
跳过客户端证书验证，不是“关掉某个开关”，而是服务端明确告诉客户端：“我不需要你提供证书”。ClientAuth 字段控制的就是这个行为，默认值就是 tls.NoClientCert，此时哪怕你配置了 ClientCAs，服务端也完全不检查、不请求、不拒绝——连接照常建立。
- 显式设
ClientAuth: tls.NoClientCert是最安全的“跳过”方式，语义清晰，无副作用 - 千万别误以为“不设
ClientAuth就等于跳过”：Go 的http.ListenAndServeTLS和tls.Listen构造的默认tls.Config确实是NoClientCert，但显式写出更可靠，避免被后续代码或中间件覆盖 - 如果已配了
ClientCAs却没设ClientAuth，行为不变；但如果误设成tls.RequireAnyClientCert或tls.VerifyClientCertIfGiven，就可能触发非预期的证书请求或静默降级
为什么设 tls.RequireAndVerifyClientCert 才算真正启用 mTLS
真正双向认证的门槛只有一个：ClientAuth 必须是 tls.RequireAndVerifyClientCert。其他值都不行：
-
tls.RequireAnyClientCert：服务端会请求证书，但不校验是否可信——收到任意垃圾证书都放行 -
tls.VerifyClientCertIfGiven：只在校验收到的证书时才走验证逻辑，但客户端完全可以不发证书，连接照样成功 -
tls.RequireAndVerifyClientCert：服务端强制请求 + 强制校验 + 校验失败直接断连，错误是remote error: tls: bad certificate
ClientCAs 为空或加载失败时的典型错误
即使 ClientAuth 设对了，ClientCAs 没配好也会让 mTLS 彻底失效。常见现象：
-
ClientCAs是 nil 或空池 → 握手失败，报错tls: client didn't provide a certificate（注意：这不是客户端没发，而是服务端没能力验证） - 加载的 PEM 内容不是 CA 根证书（比如误塞了客户端证书或私钥）→ 解析失败，
AppendCertsFromPEM返回 false，但无 panic，后续握手静默失败 - CA 证书内容正确，但和客户端所用 CA 不一致 → 验证失败，错误仍是
remote error: tls: bad certificate，没有更具体提示
调试时怎么确认客户端证书真被用了
服务端日志里看不到客户端证书详情，http.Server 默认也不暴露。必须在 TLS 层介入才能观察：
立即学习“go语言免费学习笔记（深入）”；
- 用
GetConfigForClient回调，在info.State.PeerCertificates中取原始证书链 - 解析后打印
cert.Subject.CommonName或cert.URIs（如 SPIFFE ID）做身份标记 - 别依赖
req.TLS.PeerCertificates：HTTP handler 里它可能为空，因为 TLS 握手完成时该字段未必已填充
