cert.pem必须含服务器证书+中间CA完整链，key.pem须为未加密私钥且权限≤0600，换行符必须为LF，否则ListenAndServeTLS将panic或握手失败。
不难，但容易在证书文件、权限和协议细节上卡住——真正拦住人的从来不是 Go 语法，而是 PEM 文件里少了一段中间证书，或者私钥权限是 0644 却被 crypto/tls 静默拒绝。
cert.pem 和 key.pem 必须满足哪些硬性条件
Go 的 http.ListenAndServeTLS 对证书和私钥有强校验，不满足就 panic 或握手失败，且错误信息常误导人。
-
cert.pem必须包含完整链：服务器证书 + 中间 CA（如 Let’s Encrypt 的fullchain.pem），只放域名证书会导致客户端报x509: certificate signed by unknown authority -
key.pem必须是未加密私钥（不能含DEK-Info头），用openssl rsa -in key.pem.enc -out key.pem解密 - Linux/macOS 下私钥权限必须 ≤
0600；设成0644时 crypto/tls 直接拒载，日志却只显示tls: private key does not match public key - 所有文件换行符必须是 LF（Unix 风格）；Windows 的 CRLF 会导致
tls: failed to find any PEM data in certificate input
为什么 http.ListenAndServeTLS 启动就 panic
不是代码写错，而是证书加载阶段就失败了。标准库不会等你发请求才报错，而是在调用时立刻校验并退出。
- 路径写错？通常不会 panic，而是报 “no such file”，但如果你传空字符串或相对路径（如
"./cert.pem"），运行时当前工作目录不确定，极易出错 - 证书格式错：比如把 PFX、DER 或 base64 编码的二进制内容直接当 PEM 用，Go 会读不到 BEGIN/END 块
- 自签名证书没加 SAN：Chrome 90+ 拒绝连接，报
ERR_CERT_COMMON_NAME_INVALID，生成时必须加-addext "subjectAltName = DNS:localhost,IP:127.0.0.1" - 框架误用：Gin/Echo/Fiber 不接受
http.ListenAndServeTLS，必须用各自的RunTLS方法，否则类型不匹配或 panic
TLSConfig 不配会怎样，哪些字段真得设
不配 TLSConfig 能跑通，但默认支持 TLS 1.0/1.1，现代浏览器和安全扫描工具会直接拦截或警告。
立即学习“go语言免费学习笔记（深入）”；
-
MinVersion: tls.VersionTLS12必须显式设置，否则服务端协商出 TLS 1.1 时，Chrome 会显示“连接不安全” - 禁用弱 CipherSuites 不建议硬编码；Go 1.19+ 默认已优先 AEAD 套件，仅当需兼容旧设备时裁剪，且只保留如
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - 若启用双向认证（mTLS），
ClientAuth设为tls.RequireAndVerifyClientCert后，ClientCAs必须是已加载的*x509.CertPool，不是文件路径——设错就直接拒绝连接，日志只报tls: bad certificate -
TLSConfig必须在调用srv.ListenAndServeTLS前赋值，之后修改无效
HTTP 自动跳转 HTTPS 容易漏掉的关键点
很多人以为在 HTTPS server 里加个中间件就能跳转，其实根本收不到 HTTP 请求——http.ListenAndServeTLS 只监听 TLS 端口，完全不处理明文流量。
- 必须另起一个
http.Server监听:80，用http.Redirect返回http.StatusMovedPermanently（301），不是默认的 302 - 跳转目标要写死可信域名，比如
"https://example.com" + r.URL.RequestURI()；拼r.Host有风险，它可能被恶意篡改 - 部署在 Nginx / ALB 后，应关闭 Go 层 TLS，只信任
X-Forwarded-Proto头做逻辑判断，避免双重 TLS 终止
最常被忽略的是证书链完整性与私钥权限的组合效应：即使你本地 curl -k 能通，iOS、Java 客户端或某些企业防火墙仍可能因缺中间 CA 或私钥权限过宽而静默失败——别只看自己的测试结果。
