Go中TLS配置需证书、协议、校验三者对齐：cert.pem须含服务器及中间证书，key.pem须为未加密私钥且权限≤0600，自签名证书须含正确SAN；mTLS要求ClientAuth设为RequireAndVerifyClientCert、ClientCAs加载有效CA根证书；客户端RootCAs验证服务端证书，Certificates用于mTLS身份出示；MinVersion至少TLS1.2，CipherSuites需匹配签名算法并支持PFS。
Go 里配 TLS 不是“开了就行”，证书、协议、校验三者必须对齐，漏一个就可能降级成明文或直接拒连。
http.ListenAndServeTLS 启动 HTTPS 前必须检查的四件事
这函数最省事，也最容易在启动瞬间 panic，别等上线才发现问题：
-
cert.pem必须是 PEM 格式，且内容含服务器证书 + 中间证书（如 Let’s Encrypt 的fullchain.pem），不能只放域名证书；否则客户端报x509: certificate signed by unknown authority -
key.pem必须是未加密私钥（即不含DEK-Info头），格式为-----BEGIN PRIVATE KEY-----或-----BEGIN RSA PRIVATE KEY-----；否则 panic 报tls: failed to find any PEM data in certificate input - 私钥文件权限不能高于
0600（Linux/macOS 下chmod 0600 key.pem）；权限为0644时crypto/tls会静默拒绝加载 - 若用自签名证书测试，
cert.pem的Subject Alternative Name (SAN)必须包含访问目标（如DNS:localhost,IP:127.0.0.1）；否则客户端报certificate is valid for xxx, not yyy
客户端 RootCAs 和 Certificates 怎么分工
这两个字段干的事完全不同，填反或漏填都会导致连接失败：
-
RootCAs：只负责验证服务端证书是否可信，必须加载你信任的 CA 根证书（如内网私有 CA 的ca.crt）；若服务端用自签名证书，这里就得填那个cert.pem的公钥内容 -
Certificates：只在 mTLS 场景下需要，用于向服务端出示自己的身份，值是tls.Certificate类型（由client.crt+client.key构成） - 绝不能把私钥或中间证书塞进
RootCAs；它只接受 PEM 编码的证书块（-----BEGIN CERTIFICATE-----） -
InsecureSkipVerify: true是裸奔开关，CI/CD 应扫描拦截该字段，正式环境绝不能留
服务端启用 mTLS 时 ClientAuth 和 ClientCAs 容易配错哪几个点
mTLS 不是加个证书就双向了，关键在服务端配置是否真正强制并可验证：
立即学习“go语言免费学习笔记（深入）”；
- 必须设为
tls.RequireAndVerifyClientCert，设成tls.VerifyClientCertIfGiven会导致无证书请求静默通过，形同虚设 -
ClientCAs字段必须传入已加载 PEM 内容的*x509.CertPool，不能传文件路径字符串，也不能传空池 - 服务端自己的证书（
tls.LoadX509KeyPair("server.crt", "server.key")）和客户端 CA 证书（用于验对方）是两套独立文件，别混用 - 若客户端证书由私有 CA 签发，服务端
ClientCAs加载的必须是该 CA 的根证书（ca.crt），不是中间证书或服务端证书
gRPC Server 怎么加载 TLS 证书
gRPC Server 必须用 credentials.NewTLS 构造 tls 凭证，不能直接传 pem 路径：
- 常见错误是把证书路径直接塞进
grpc.Creds——这会 panic，报错类似invalid memory address or nil pointer dereference，因为底层期待的是已初始化的credentials.TransportCredentials实例 - 先用
os.ReadFile读取server.crt和server.key - 调用
tls.X509KeyPair解析得到tls.Certificate - 构造
tls.Config，注意设置ClientAuth: tls.RequireAndVerifyClientCert（如需双向认证） - 用
credentials.NewTLS包一层，传给grpc.Creds
真正容易被忽略的不是代码怎么写，而是证书链顺序、私钥权限、SAN 字段是否覆盖所有访问方式——这些地方出错，日志往往不报具体原因，只卡在 handshake failed 或 remote error: tls: bad certificate。
