cert.verify() 返回 nil 不代表证书可信，仅完成基础链式信任和时间校验，生产环境必须手动补全 san 匹配、ocsp/crl 吊销检查等逻辑，否则不满足合规要求。
cert.Verify() 返回 nil 不代表证书可信，它只做了最基础的链式信任和时间校验，连 SAN 匹配、OCSP 吊销检查都默认跳过。生产环境必须手动补全逻辑，否则等于裸奔。
VerifyOptions.Roots 和 DNSName 必须同时设置
这两个字段是硬性绑定的：缺一不可，否则验证结果无意义。
-
Roots必须是非空的*x509.CertPool，不能为nil；若传nil，Go 会 fallback 到系统根池，可能误信你不打算信任的 CA -
DNSName必须设为你实际访问的目标主机名（如"api.internal"），不能留空、不能传 IP（除非证书DNSNames或IPAddresses明确包含该 IP） - 通配符匹配有严格规则：
"*.svc.cluster.local"只匹配一级子域，"foo.svc.cluster.local"✅，"foo.bar.svc.cluster.local"❌ - 若服务端证书含多个 SAN，但
DNSName不在其中，Verify()仍会返回nil（因为不校验），但后续tls.Dial或http.Client会报x509: certificate is valid for xxx, not yyy
证书链顺序错误导致 Verify 静默失败或 “unknown authority”
Go 要求传给 Verify() 的 rawCerts（比如从 tls.Conn.ConnectionState().PeerCertificates 拿到的）必须是完整且有序的链：叶证书在前，中间 CA 在后，根 CA 通常不传（由 Roots 提供）。
- 只传叶证书，没附中间证书 →
Verify()找不到签发者，报"x509: certificate signed by unknown authority" - 中间证书顺序颠倒（如中间 CA 在前、叶证书在后）→ 可能静默失败，或返回不完整链，调试时极难定位
- 调试建议：用
openssl s_client -connect host:port -showcerts看服务端实际发送的证书顺序，按此拼成 PEM 文件再本地复现 - 多证书 PEM 文件需循环调用
pem.Decode，不能只取第一个 block
ParseCertificate 接收的是 DER 字节，不是 PEM 块
直接把 PEM 文件内容（含 -----BEGIN CERTIFICATE----- 头尾）传给 x509.ParseCertificate() 会 panic 或返回 crypto/x509: malformed certificate。
- 必须先用
pem.Decode()提取block.Bytes，再传给ParseCertificate() - 务必校验
block.Type == "CERTIFICATE"，避免把PRIVATE KEY或CERTIFICATE REQUEST当成证书解析 - Windows 下 PEM 文件带
\r\n换行可能导致pem.Decode返回nil，建议先bytes.TrimSpace() - 自签名 CA 证书若没设
IsCA: true和KeyUsageCertSign，即使加载进Roots，Verify()也会拒绝信任
吊销检查（OCSP/CRL）必须自己实现
cert.Verify() 默认完全不查 OCSP 或 CRL，这是 Go 的明确设计选择，不是 bug。
- 若需吊销检查，必须在
tls.Config.VerifyPeerCertificate回调里手动解析rawCerts，调用ocsp.Request()或下载解析 CRL 分发点 -
VerifyPeerCertificate收到的rawCerts是[][]byte（DER 格式），不是已解析的*x509.Certificate，需先用x509.ParseCertificate()解析 - 第一个元素
rawCerts[0]是叶证书，后续是中间链；根证书不在其中，别试图解析它 - 忽略吊销状态在内网或短生命周期证书场景可能可接受，但在面向公网的服务中，这属于高风险盲区
最容易被忽略的是：即使你把所有参数都设对了，Verify() 也通过了，只要没做吊销检查 + 没显式校验 SAN 匹配，就仍然无法满足 PCI DSS、等保三级等合规要求。这不是“够用就行”的环节，而是必须显式覆盖的边界。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
