Go客户端TLS加密关键在于显式配置http.Transport的TLSClientConfig：RootCAs用于验证服务端证书，Certificates用于mTLS时出示客户端身份，二者缺一不可且分工明确。
Go 客户端用 TLS 加密传输，关键不是“加证书”，而是让 http.Client 真正把证书发出去、且能正确验证服务端——漏掉 RootCAs 或 Certificates 任一字段，连接就卡在握手阶段，报错却很模糊。
为什么 http.DefaultTransport 不发客户端证书
默认的 http.DefaultTransport 根本不读取任何本地证书文件，也不校验服务端证书链（除非你手动关掉校验）。它只走系统默认根证书池，对 mTLS 完全无感。
- 必须显式构造
*http.Transport，再赋给http.Client.Transport -
Transport.TLSClientConfig是唯一生效入口，http.Client自身没有证书相关字段 - 若只调
tls.LoadX509KeyPair("client.crt", "client.key")却没塞进TLSClientConfig.Certificates，握手直接失败，日志仅显示transport: authentication handshake failed
Certificates 和 RootCAs 必须分工明确
这两个字段干的事完全不重叠，填反或漏填都会导致连接失败：
-
RootCAs：只用于验证**服务端证书是否可信**，必须加载你信任的 CA 根证书（如内网私有 CA 的ca.crt）；若服务端用自签名证书，这里就得填那个cert.pem的公钥内容 -
Certificates：只在 mTLS 场景下需要，用于向服务端**出示自己的身份**，值是tls.Certificate类型（由client.crt+client.key构成） - 绝不能把私钥或中间证书塞进
RootCAs；它只接受 PEM 编码的证书块（-----BEGIN CERTIFICATE-----）
客户端证书文件必须满足三个硬条件
哪怕路径和代码都对，证书文件本身不合规，Go 也会静默失败：
立即学习“go语言免费学习笔记（深入）”；
-
client.crt必须含完整链：终端证书在前，中间证书在后；顺序颠倒会导致某些服务端（如 Nginx 前置）校验失败 -
client.key必须是未加密私钥（不含DEK-Info头），可用openssl rsa -in key_encrypted.pem -out key.pem解密 - 私钥文件权限必须 ≤
0600（Linux/macOS），权限为0644时crypto/tls会拒绝加载，但错误提示常是误导性的tls: private key does not match public key
ServerName 和 InsecureSkipVerify 的真实作用
这两个字段常被误用，但它们影响的是完全不同的环节：
-
ServerName：决定 SNI 字段发什么、以及服务端证书里的 SAN 是否匹配；不设会导致x509: certificate is valid for example.com, not 127.0.0.1类错误 -
InsecureSkipVerify: true是裸奔开关：它绕过整个证书链验证，连 SNI 和 ALPN 都可能失效；CI/CD 应扫描拦截该字段，正式环境绝不能出现 - 真正该做的是用
RootCAs显式信任——哪怕自签名，也应加载其公钥，而不是跳过
最易被忽略的一点：RootCAs 必须非空且已加载有效证书，否则即使服务端配置了 mTLS，客户端也拿不出可信链去完成握手；而 Go 不会在构建 tls.Config 时主动报错，问题往往拖到第一次请求才暴露。
