gin.runtls不能硬编码证书路径，因工作目录不一致会导致静默panic或accept tcp: use of closed network connection；私钥权限非0600会误报tls: private key does not match public key；必须用绝对路径或动态拼接，且私钥权限须为0600、证书链须完整。
gin.RunTLS 为什么不能硬编码证书路径
硬编码 cert.pem 和 key.pem 路径（比如写死 "./certs/cert.pem"）在开发阶段看似可行，但上线后极易因工作目录不一致导致启动失败——Go 不会报“文件不存在”，而是静默 panic 或抛出 accept tcp: use of closed network connection。更危险的是，若私钥文件权限为 0644，Go 会拒绝加载并误报 tls: private key does not match public key，实际只是权限校验失败。
- 必须用绝对路径，或通过
os.Executable()+filepath.Dir()动态拼接证书位置 - 私钥文件权限必须设为
0600（Linux/macOS 下用chmod 0600 key.pem） - 证书文件需是 PEM 格式，且
fullchain.pem必须包含域名证书 + 所有中间 CA，缺一不可
Basic Auth 凭据绝不能硬编码进 gin.Accounts
把账号密码直接写成 gin.Accounts{"admin": "p@ssw0rd"} 是高危操作：二进制里可被 strings 命令提取；进程环境变量中若用 os.Getenv 加载，也会暴露在 /proc/<pid>/environ</pid> 中，任何能登录服务器的用户都可读取。
- 密码应从加密的配置文件（如 age 加密）或安全的 secrets 管理服务（Vault、AWS Secrets Manager）动态解密获取
- 若必须用环境变量，至少用
syscall.Setenv在启动后立即清空原始变量 - 校验逻辑需用 constant-time 比较（如
crypto/subtle.ConstantTimeCompare），避免时序攻击
HTTP → HTTPS 跳转不是中间件，必须双服务监听
试图用一个 gin.Engine 实例同时处理 HTTP 和 HTTPS，并靠中间件做 301 跳转，完全无效——http.Server 不支持单实例混用 TLS 和非 TLS 连接。Gin 的 RunTLS 只负责 HTTPS，HTTP 端口必须另起一个独立服务。
- HTTP 服务只做一件事：对所有请求返回
301 Moved Permanently，Location 头拼接"https://" + r.Host + r.RequestURI - 两个服务必须分别启动，HTTPS 服务用
srv.ListenAndServeTLS()，HTTP 服务用http.ListenAndServe() - 若部署在 Nginx 或 ALB 后，跳转应由前置代理完成，Gin 内部无需实现
手动构建 http.Server 才能真正控制 TLS 安全边界
直接调 r.RunTLS(":443", "cert.pem", "key.pem") 看似省事，但它绕过了 http.Server 的关键安全配置项：无法设置 ReadTimeout 防慢速攻击，无法禁用 TLS 1.0/1.1，也无法限制最大 header 大小。
- 生产环境务必手动构造
&http.Server{Addr: ":443", Handler: r, TLSConfig: &tls.Config{MinVersion: tls.VersionTLS12}} -
TLSConfig.CipherSuites应显式指定强套件，如tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - 记得关闭
TLSConfig.SessionTicketsDisabled并设置TLSConfig.ClientAuth（如需双向认证）
