需调用 conn.ConnectionState().PeerCertificates 获取已验证证书链，前提是 handshake 已成功完成；该字段按叶到根顺序返回证书，未完成握手或验证失败时为空切片。
如何从 tls.Conn 获取已验证的证书链
tls.Conn 本身不直接暴露证书，必须通过 ConnectionState() 方法获取握手后的完整状态。PeerCertificates 字段才是你要的叶证书（服务端证书）及其完整链，按从叶到根顺序排列。如果连接未完成握手或验证失败，该字段为空切片——别假设它一定有值。
- 调用
conn.ConnectionState().PeerCertificates前，确保conn.Handshake()已成功返回 nil（或由Read/Write隐式触发） - 若只关心叶证书，取
certs[0]即可；但生产环境建议校验整条链，尤其在 mTLS 场景下需确认客户端证书是否由可信 CA 签发 - 证书解析失败常见于时间戳越界（如系统时钟严重偏差）、签名算法不被本地 crypto/x509 支持（如某些国密 SM2 证书），此时
cert.Verify()会返回 error
ConnectionState() 返回结构里哪些字段真正可靠
ConnectionState 是只读快照，但并非所有字段在每次调用时都有效。比如 ServerName 仅当客户端发送了 SNI 扩展且服务端启用了 SNI 支持时才有值；VerifiedChains 则依赖 VerifyPeerCertificate 回调是否被设置并成功执行。
-
Version和CipherSuite总是可用，反映实际协商结果（如tls.VersionTLS13、tls.TLS_AES_128_GCM_SHA256） -
HandshakeComplete是关键判断依据：为 false 时，PeerCertificates、VerifiedChains等均不可信 -
DidResume表示是否复用会话，但注意：会话票据（session ticket）恢复时，PeerCertificates仍存在，而 PSK 恢复时可能为空（取决于服务端实现）
为什么调用 ConnectionState() 后修改 config 不影响当前连接
tls.Config 是连接建立前的“蓝图”，一旦 tls.ClientConn 或 tls.ServerConn 初始化完成，其内部状态（包括加密上下文、密钥材料、证书缓存）就与原始 config 解耦。后续对 config 字段的修改，比如改 MinVersion 或追加 RootCAs，对已存在的 tls.Conn 实例完全无效。
- 常见误操作：在连接池中复用
tls.Config实例，并试图动态更新RootCAs来支持新 CA —— 这不会让已有连接信任新 CA - 若需热更新信任根，必须重建连接，或在
GetCertificate/VerifyPeerCertificate回调中实时加载（后者更安全，但回调内不能阻塞） -
ServerName字段在客户端 config 中仅用于构造 ClientHello 的 SNI，连接建立后即固化，改它无意义
并发读写时 ConnectionState() 的线程安全性
ConnectionState() 方法本身是线程安全的，它返回的是连接状态的拷贝，不涉及锁竞争。但要注意：这个拷贝反映的是调用瞬间的状态，不是原子快照——比如你刚拿到 PeerCertificates，紧接着对方就断开了连接，证书数据依然有效，但连接已不可用。
- 不要在 goroutine 里长期持有
ConnectionState结构体引用，它不含指针指向 conn 内部缓冲区，但也不代表连接持续活跃 - 若需在多个 goroutine 中频繁检查证书有效期，建议提取
NotAfter时间后缓存为本地time.Time变量，避免反复调用方法和解引用 - 特别注意：证书链中的
*x509.Certificate是不可变对象，可安全跨 goroutine 使用，但其Raw字段是原始 ASN.1 编码字节，若需反复解析（如提取 SAN），应提前做一次dnsNames := cert.DNSNames并缓存结果
证书链的解析和状态判断看似简单，但容易忽略握手是否真正完成、证书是否被验证、以及 ConnectionState 快照的时间窗口。最常踩的坑是把未完成握手的连接当成有效连接去取证书，或者误以为修改 config 能影响已有连接——这两类问题在线上环境往往表现为偶发 panic 或证书校验静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
