gin启用mtls需手动构造http.server并配置tlsconfig：clientauth设为tls.requireandverifyclientcert，clientcas加载可信ca证书池，服务端从c.request.tls.peercertificates[0]提取subjectkeyid校验身份，禁用相对路径与basicauth替代方案。
如何在 Gin 中启用 TLS 双向认证（mTLS）
Gin 本身不提供开箱即用的 mTLS 支持，必须绕过 r.RunTLS()，手动构造 http.Server 并配置 TLSConfig；否则服务端只会接受客户端证书，但不会强制验证、也不会拒绝未提供证书的连接。
关键不是“加证书”，而是让服务端主动要求并校验——这一步漏掉，就退化成普通单向 HTTPS。
-
TLSConfig.ClientAuth必须设为tls.RequireAndVerifyClientCert（不能用tls.VerifyClientCertIfGiven） -
TLSConfig.ClientCAs必须加载可信 CA 证书池（*x509.CertPool），用于验证客户端证书签名链；不是放客户端证书，而是放签发它们的根或中间 CA - 私钥文件权限必须是
0600，否则 Go 会静默失败，报错类似tls: private key does not match public key
证书路径与加载方式常见错误
服务端启动时找不到 CA 证书或私钥，往往不是路径写错，而是工作目录不一致导致相对路径失效；Go 不会明确提示“文件不存在”，而是 panic 或抛出 accept tcp: use of closed network connection 这类误导性错误。
- 证书路径建议统一用绝对路径，例如
/etc/ssl/mtls/ca.pem；若用相对路径，确保从二进制所在目录执行（不是go run的源码目录） - 加载 CA 证书池不能直接
ioutil.ReadFile后硬塞，必须用x509.NewCertPool()+AppendCertsFromPEM() - 客户端证书需完整链（含中间 CA），否则服务端验证失败，日志里只显示
x509: certificate signed by unknown authority，不指明是哪一级缺失
如何从请求中提取并校验客户端身份
双向认证通过后，客户端证书信息保存在 c.Request.TLS.PeerCertificates，但直接取 Subject.CommonName 做白名单极不安全——它可被任意伪造；应基于不可篡改的 SubjectKeyId 或证书指纹做校验。
- 服务端拿到
PeerCertificates[0]后，调用cert.SubjectKeyId得到字节数组，再 hex 编码为字符串用于比对 - 白名单建议存在内存 map 或 Redis 中，避免每次读文件；key 用
hex.EncodeToString(cert.SubjectKeyId)，value 可存用户角色等元数据 - 注意：若客户端发了多张证书（如带中间 CA），
PeerCertificates是按链顺序排列的，首项才是终端实体证书
为什么用 gin.BasicAuth + HTTPS 不能替代 mTLS
Basic Auth 依赖密码传输，即使走 HTTPS，仍存在凭证复用、泄露、爆破风险；而 mTLS 把身份绑定到设备/客户端证书上，天然防重放、无需密码管理、且可精细控制每个证书的访问范围。
- Basic Auth 的密码明文存在于 HTTP 头，服务端需实时解码比对；mTLS 在 TLS 握手阶段完成身份确认，后续 HTTP 层完全无感知
- Basic Auth 无法区分“谁在用这个账号”，mTLS 可精确到某台设备（如 IoT 终端）、某个部署实例（如 Kubernetes Pod）
- 若你已用 Let’s Encrypt 管理服务端证书，别误以为能复用同一套证书做客户端认证——LE 不签发客户端证书，必须自建 CA 或用 cfssl 等工具签发
ClientCAs 加载失败和 SubjectKeyId 提取逻辑没处理空值。一旦证书链不全或客户端没发证书，PeerCertificates 就是空 slice，直接取 [0] 会 panic。
