Go框架HTTPS必须用对应RunTLS方法（如Gin.RunTLS），不能直接传框架实例给http.ListenAndServeTLS，因类型不匹配；需确保PEM证书链完整、私钥未加密且权限0600、换行符为LF。
http.ListenAndServeTLS 不能直接用于框架 HTTPS 配置——它只接受 http.Handler，而框架（如 Gin、Echo、Fiber）返回的是自定义 Engine 或 App 类型，必须显式调用其 RunTLS 或包装为 http.Handler 后再传入。
框架启动 HTTPS 必须用对应 RunTLS 方法，不是 ListenAndServeTLS
几乎所有主流 Go Web 框架都封装了 TLS 启动逻辑，但接口不统一。硬套标准库函数会编译失败或 panic。
- Gin：用
engine.RunTLS("cert.pem", "key.pem")，内部自动处理证书加载和端口绑定；传错路径会 panic 报tls: failed to find any PEM data in certificate input - Echo：用
e.StartTLS(":443", "cert.pem", "key.pem")；若证书链不完整（缺中间 CA），iOS 和 Java 客户端大概率握手失败，错误日志里只显示tls: bad certificate - Fiber：用
app.ListenTLS(":443", "cert.pem", "key.pem")；注意它默认不校验私钥权限，但 Linux 上若key.pem权限是0644，Go 底层crypto/tls仍会拒绝加载并静默退出 - 别把框架实例直接塞进
http.ListenAndServeTLS：比如http.ListenAndServeTLS(":443", "c.pem", "k.pem", ginEngine)会报类型错误——*gin.Engine不实现http.Handler接口（Gin v1.9+ 已改，但旧项目常见）
证书链拼接错误是框架 HTTPS 启动失败最常见原因
框架底层仍调用 tls.LoadX509KeyPair，对证书格式要求和标准库完全一致。所谓“框架更简单”，只是隐藏了调用细节，没绕过 PEM 规则。
- Let’s Encrypt 用户必须用
fullchain.pem（cert + chain），不能只传cert.pem；否则浏览器显示NET::ERR_CERT_AUTHORITY_INVALID，curl 提示unable to get local issuer certificate - 自签名证书调试时，
openssl req命令必须加-addext "subjectAltName = DNS:localhost,IP:127.0.0.1"，否则 Chrome 90+ 直接拒绝连接（报ERR_CERT_COMMON_NAME_INVALID） - 证书文件里混入 Windows 的 CRLF 换行符会导致解析失败，错误信息是
tls: failed to find any PEM data；用dos2unix cert.pem key.pem修复 - 私钥若用
openssl genrsa -aes256生成，必须先解密：openssl rsa -in key.pem.enc -out key.pem；框架不会提示“密钥被加密”，只会卡在 TLS handshake 阶段
需要定制 TLS 行为时，框架必须暴露 http.Server 实例
所有框架的 RunTLS 方法都是快捷封装，无法设置 TLSConfig.MinVersion 或启用 mTLS。真要控制协议版本或客户端证书，得拿到底层 *http.Server。
立即学习“go语言免费学习笔记（深入）”；
- Gin：用
httpServer := &http.Server{Addr: ":443", Handler: engine, TLSConfig: tlsConfig}，然后调httpServer.ListenAndServeTLS("cert.pem", "key.pem")；注意此时不能再调engine.RunTLS - Echo：
e.Server.TLSConfig = tlsConfig，再调e.StartTLS；但e.Server是公开字段，可直接改 - Fiber：没有直接暴露
http.Server，需用app.Listener自建 listener：ln, _ := tls.Listen("tcp", ":443", tlsConfig)，再app.Listener(ln) - 禁用 TLS 1.1 及以下必须设
MinVersion: tls.VersionTLS12；设成tls.VersionTLS13会断掉 Android 4.4–7.0 的 WebView 请求
HTTP 自动跳转 HTTPS 在框架中容易配错端口和重定向逻辑
框架本身不提供 HTTP→HTTPS 跳转能力，必须手动启两个 server：一个监听 :80 做 301 重定向，另一个监听 :443 做 HTTPS 服务。
- 别在 :443 server 里写
if r.TLS == nil { http.Redirect(...) }——r.TLS永远不为 nil，因为只有 HTTPS 请求才能到达这个 server - :80 server 的重定向目标必须写死域名，比如
"https://example.com" + r.URL.RequestURI()；用"https://" + r.Host + r.URL.RequestURI()有风险，r.Host可被恶意构造 - 如果部署在 Nginx / ALB 后，Go 层应关闭 :80 server，改用
X-Forwarded-Proto判断是否跳转，并确保 Nginx 配置了proxy_set_header X-Forwarded-Proto $scheme; - 某些框架（如 Echo）提供
e.Pre(middleware.HTTPSRedirect())，但它只检查r.TLS，在反向代理场景下失效，慎用
证书链顺序、私钥权限、换行符风格这三点，框架不会帮你校验，出问题时日志往往不报具体原因，只能靠 openssl x509 -in cert.pem -text -noout 和 ls -l 手动排查。
