Go服务端提取验证客户端证书，必须在TLS握手完成后从r.TLS.PeerCertificates获取已验证证书链；需配置ClientAuth为RequireAndVerifyClientCert且ClientCAs预加载可信CA，否则证书链为空或校验失效。
Go 服务端要提取并验证客户端证书，核心就一条：必须在 TLS 握手完成后、HTTP 请求处理阶段，从 r.TLS.PeerCertificates 拿已验证的证书链——不是从原始字节里手动解析，也不是靠中间件“猜”有没有证书。
服务端启用客户端证书验证必须配 ClientAuth 和 ClientCAs
不设 tls.Config.ClientAuth，r.TLS.PeerCertificates 永远是空切片；只设 RequireAnyClientCert 而不配 ClientCAs，TLS 层会接受任意证书（包括自签名），但不会做信任链校验，等于白开。
-
ClientAuth: tls.RequireAndVerifyClientCert是最常用且安全的选择，强制校验并拒绝无效证书 -
ClientCAs: x509.NewCertPool()必须提前加载 CA 证书（PEM 格式），否则所有客户端证书都会被拒 - 如果用
tls.VerifyPeerCertificate自定义校验逻辑，ClientCAs可为空，但需自己实现完整验证（含签名、有效期、吊销等）
r.TLS.PeerCertificates 返回的是已验证的证书链，首项是客户端叶证书
这个切片按“叶证书 → 中间 CA → 根 CA”顺序排列，r.TLS.PeerCertificates[0] 就是客户端提交的终端实体证书，且已通过 ClientCAs 或自定义逻辑验证过。别再试图从 r.TLS.RawConn 或握手原始数据里去解析——那没经过验证，不可信。
- 证书字段可直接访问：
cert.Subject.CommonName、cert.Subject.Organization、cert.NotAfter等 - 注意：X.509 v3 证书中
CommonName已被主流浏览器弃用，优先检查cert.DNSNames或cert.EmailAddresses - 若需提取公钥，直接用
cert.PublicKey（类型为interface{}，通常是*rsa.PublicKey或*ecdsa.PublicKey）
常见错误：证书存在但 r.TLS.PeerCertificates 为空
这几乎全是配置或协议层问题，和业务代码无关。
- 客户端没发证书：确认 HTTP 客户端设置了
tls.Config.Certificates，且服务端未启用InsecureSkipVerify（它只影响服务端证书验证） - 服务端 TLS 配置没生效：检查
http.ListenAndServeTLS是否用了正确的tls.Config，而不是默认 nil - 反向代理（如 Nginx）终止了 TLS：此时 Go 服务端看到的是明文 HTTP，
r.TLS为 nil；必须让代理透传证书（如 Nginx 的proxy_ssl_certificate+proxy_ssl_certificate_key并开启proxy_pass_request_headers on），或改用 TLS 直连
真正容易被忽略的点是：证书链完整性。客户端必须发送完整的证书链（含中间 CA），否则即使根 CA 在 ClientCAs 里，Go 的验证器也可能因无法构建路径而失败——这不是 bug，是 X.509 验证的正常行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
