http.ListenAndServeTLS启动前必须检查四件事：cert.pem须含完整证书链（域名证+中间CA）、key.pem须为未加密私钥、Linux/macOS下私钥权限≤0600、自签名证书必须含正确SAN（如dns:localhost或ip:127.0.0.1）。
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 不是加个证书就双向了，关键在服务端配置是否真正强制并可验证：
- 必须设为
tls.RequireAndVerifyClientCert，设成tls.VerifyClientCertIfGiven会导致无证书请求静默通过，形同虚设 -
ClientCAs字段必须传入已加载 PEM 内容的*x509.CertPool，不能传文件路径字符串，也不能传空池 -
TLSConfig.Certificates仍需提供服务端证书（即server.crt+server.key），否则连单向 TLS 都不成立 - 若用 gRPC，
grpc.WithTransportCredentials(credentials.NewTLS(...))中的tls.Config同样要满足上述要求，否则握手直接失败
Go 里配 TLS 不是“开了就行”，证书、协议、校验三者必须对齐
漏一个就可能降级成明文或直接拒连：
立即学习“go语言免费学习笔记（深入）”；
-
MinVersion至少设为tls.VersionTLS12，CipherSuites需匹配签名算法并支持 PFS（如 ECDHE 系列），否则旧客户端可能连不上，新客户端可能被降级 - 自签名证书生成时，OpenSSL 必须显式指定
subjectAltName（通过openssl.conf配置），gRPC 和现代 HTTP/2 客户端会严格校验 SAN，缺项即拒连 - 服务端和客户端的
ServerName（如tls.Config.ServerName）若与证书 SAN 不一致，也会触发验证失败——尤其在 Kubernetes Service DNS 场景下，DNS.2 = mysvc.default.svc.cluster.local这类条目不能漏
