cert.verify()不查ocsp是设计使然，仅执行链式信任、有效期和基础san匹配，完全跳过吊销检查；生产环境必须通过verifypeercertificate回调手动实现ocsp请求、响应解析与签名验证。
Go 语言默认不检查 OCSP 状态，必须手动实现；否则证书即使已被吊销，cert.Verify() 仍可能返回 nil。
为什么 cert.Verify() 不查 OCSP
Go 的 x509.Certificate.Verify() 只做链式信任、有效期和基本 SAN 匹配，它完全跳过吊销检查——既不发 OCSP 请求，也不下载解析 CRL。这是设计使然，不是 bug。生产环境若依赖它判断证书是否可信，等于裸奔。
-
VerifyOptions.Roots为空时会 fallback 到系统根池，行为不可控 -
VerifyOptions.DNSName不设值则跳过域名匹配，SAN 校验形同虚设 - 吊销状态字段（如
OCSPServer扩展）被读取但从未被使用
如何在 TLS 握手中插入 OCSP 检查
关键是在 tls.Config.VerifyPeerCertificate 回调里拦截证书链，对叶证书发起 OCSP 查询并验证响应签名。注意：必须用证书中 AuthorityInfoAccess 扩展里的 OCSPServer 地址，不能硬编码。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 提取叶证书的
OCSPServer：遍历cert.Extensions，找 OID1.3.6.1.5.5.7.1.24对应的 URI - 构造请求需用
ocsp.CreateRequest()，传入叶证书和其 issuer 证书（不能只传公钥） - HTTP 请求头必须设
Content-Type: application/ocsp-request，否则多数 OCSP 响应者拒绝 - 响应要用
ocsp.ParseResponse()解析，并用 issuer 的公钥验证签名——别忘了校验ResponseBytes.Status和ProducedAt是否在合理时间窗口内
常见失败原因和绕不过去的坑
实际跑通 OCSP 检查比写几行代码难得多，多数失败不是逻辑错，而是协议细节或环境问题。
- OCSP 响应者返回
unauthorized：说明该 CA 未授权这个 issuer 使用该 OCSP 服务，得换 issuer 或查 AIA 扩展是否含多个 URL -
ocsp.ParseResponse()panic：常见于响应体是 gzip 压缩但没解压，或 HTTP 状态码非 200 却直接读 body - 超时卡死：OCSP 是阻塞操作，务必设
http.Client.Timeout（建议 ≤ 3s），且不能复用全局 client（TLS 握手阶段并发高） - 证书链不完整：
VerifyPeerCertificate收到的rawCerts可能缺 issuer，需提前补全或从本地 CertPool 查找
要不要用 OCSP Stapling
服务端启用 OCSP Stapling（即 tls.Config.GetConfigForClient 中调用 ocsp.Response 并填入 Certificate.OCSPStaple）可把 OCSP 响应随握手一起下发，避免客户端直连 OCSP 服务器。但它解决的是性能和隐私问题，不替代客户端主动检查——因为 stapled 响应本身也可能过期或伪造，仍需验证签名和时间戳。
真正容易被忽略的是：OCSP 响应的 NextUpdate 字段不是“有效期截止”，而是“建议下次查询时间”；而 ThisUpdate 才是状态生效起点。生产代码里必须同时校验这两个时间，且允许一定漂移（比如 5 分钟），否则网络时间不同步会导致误判。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
