go中echo启用https需确保cert.pem含完整证书链（域名证书+中间ca）、key.pem为未加密私钥且权限0600、文件使用lf换行符；否则将静默失败或握手错误。
echo.StartTLS 证书路径必须可读，且不能含 Windows 换行符
调用 e.StartTLS(":443", "cert.pem", "key.pem") 时，Echo 会直接传给 tls.LoadX509KeyPair。一旦文件里混入 CRLF（\r\n），Go 标准库解析失败，报错 tls: failed to find any PEM data in certificate input，服务静默退出——没有 panic，也不监听端口。
常见诱因：
- 用 Notepad++ 或 Windows 记事本保存的 PEM 文件
- Git 在 Windows 上启用了
core.autocrlf=true，检出时自动转 CRLF - CI/CD 构建镜像中从宿主机挂载证书，但宿主机是 Windows
修复方式统一：运行 dos2unix cert.pem key.pem；或在 Linux/macOS 下用 sed -i 's/\r$//' cert.pem key.pem。验证是否修复：用 file cert.pem 输出应为 cert.pem: PEM certificate，而非 with CRLF line terminators。
证书链不完整会导致 iOS 和 Java 客户端握手失败
只放域名证书（cert.pem）不放中间 CA，Chrome 和 curl 可能仍能连上，但 iOS Safari、Android WebView、Java HttpClient 会直接报 tls: bad certificate，且日志无更多线索。
正确做法是把中间证书拼在域名证书后面：
cat domain.crt intermediate.crt > cert.pem
注意顺序：域名证书在前，中间 CA 在后，根 CA 不需要（客户端自带）。验证链是否完整：
- 用
openssl verify -CAfile root.crt cert.pem（需有根证书） - 或在线工具如 SSL Labs 的 SSL Test，看 “Chain issues” 是否为 “None”
自签名场景下，必须把自签 CA 的 cacert.pem 也拼进 cert.pem，否则所有客户端都拒绝连接。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
私钥不能加密，权限必须是 0600
如果私钥用 openssl genrsa -aes256 生成，它带密码保护。Echo 启动时不会提示“密钥被加密”，而是卡在 TLS handshake 阶段——客户端超时，服务端无日志。这是最常被忽略的静默失败点。
解密命令：
openssl rsa -in key.pem.enc -out key.pem
Linux 上还必须设权限：
-
chmod 0600 key.pem—— Echo v2+ 不校验权限，但 Go 底层crypto/tls在 Linux 下若权限宽松（如 0644），会直接拒绝加载并退出 - macOS 和 Windows 不强制此限制，但为一致性建议统一设为 0600
验证方式：ls -l key.pem 输出中应为 -rw-------。
HTTP/2 自动启用，但依赖证书合法性和 ALPN 协商
Echo v4 调用 e.StartTLS 默认启用 HTTP/2，无需额外配置。但它不是“开关”，而是依赖底层 net/http 的 ALPN 协商结果。若证书不被信任（如自签名未导入系统信任库）、或客户端不支持 h2 ALPN，连接就会回退到 HTTP/1.1。
验证是否真走 HTTP/2：
-
curl -I --http2 https://localhost:443/health—— 返回头中含HTTP/2 200才算成功 - 浏览器开发者工具 → Network → 点击请求 → Headers → 查看
Protocol字段
本地开发建议用 mkcert 生成证书，它会自动把根证书注入系统信任库，避免 Chrome/Firefox 拒绝连接；别用 openssl req -new -x509 直接生成，除非你手动把 CA 加进系统信任链。
