根本原因是Go的net/http要求HTTP/2必须通过TLS启动且证书被客户端信任；自签名、Let’s Encrypt staging证书或中间链缺失均会导致客户端降级回HTTP/1.1。
为什么 e.StartAutoTLS 启动后 HTTPS 仍走 HTTP/1.1？
根本原因不是 Echo 框架没开 HTTP/2，而是 Go 的 net/http 要求：HTTP/2 必须通过 TLS 启动，且证书必须被客户端信任。自签名、Let’s Encrypt staging 环境证书、或中间证书缺失，都会导致浏览器/curl 降级回 HTTP/1.1。
验证方式很简单：curl -I --http2 https://localhost:443/ping。若返回 HTTP/2 200 且无重定向，说明成功；若返回 HTTP/1.1 301 或直接报错，就该查证书链或 ALPN 协商了。
- 确保用的是 Let’s Encrypt production 环境证书（
--staging不行） -
e.StartAutoTLS内部调用的是http.ListenAndServeTLS，它依赖系统信任根；本地开发建议用mkcert生成可信证书，别用自签 - 检查 Nginx 或反向代理是否在前端终止 TLS 并转发 HTTP 到 Echo —— 这种情况下 Echo 根本看不到 TLS，自然不启用 HTTP/2
如何让 e.AutoTLSManager 正确缓存并复用会话？
e.AutoTLSManager 默认使用内存缓存（cache.DirCache），但只管证书获取与存储，不控制 TLS 会话复用行为。真正影响复用的是底层 http.Server.TLSConfig 的配置。
你需要手动设置 TLSConfig 并注入到 Echo 实例：
srv := &http.Server{
Addr: ":443",
Handler: e,
TLSConfig: &tls.Config{
MinVersion: tls.VersionTLS12,
CurvePreferences: []tls.CurveID{tls.CurveP256, tls.X25519},
SessionTicketsDisabled: false,
SessionTicketKey: [...]byte{ /* 32-byte key */ },
ClientSessionCache: tls.NewLRUClientSessionCache(1024),
},
}
srv.ListenAndServeTLS("", "") // 空字符串表示由 AutoTLSManager 提供
-
SessionTicketKey必须固定且跨进程一致，否则多实例部署时会话无法复用 -
ClientSessionCache大小建议 ≥ 1024，太小会导致高频失效，引发完整握手风暴 - 别漏掉
MinVersion: tls.VersionTLS12—— 否则 Go 默认允许 TLS 1.0/1.1，既不安全也拖慢协商
证书链不完整导致页面加载卡顿，怎么快速定位？
现象是：HTTPS 页面打开慢、部分安卓/iOS 设备白屏、Chrome 控制台报 NET::ERR_CERT_INVALID 或提示“证书不可信”，但 openssl s_client -connect example.com:443 -servername example.com 显示证书有效 —— 这基本就是中间证书缺失。
用这行命令一次看清全链是否下发：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep "s:" | head -n 3
输出应有 2–3 行，形如 s:/CN=example.com（域名证书）、s:/CN=R3（Let’s Encrypt 中间证书）、s:/CN=ISRG Root X1（根证书）。如果只有第一行，说明服务器没发中间证书。
- Nginx 配置需用
ssl_certificate指向包含域名证书 + 中间证书的合并文件（fullchain.pem），不是cert.pem - 用
e.AutoTLSManager.Cache自定义缓存时，确保写入的是完整链；acme.sh 默认生成的fullchain.cer才是正确选择 - 别把根证书塞进
ssl_certificate—— 浏览器不认，反而可能触发校验失败
HTTP/2 多路复用失效的隐藏原因
即使协议协商成功，你仍可能观察到并发请求串行加载、首字节延迟高 —— 这往往不是协议问题，而是应用层阻塞了流调度。
典型诱因：
- Handler 中调用
io.ReadAll(r.Body)后未关闭r.Body，导致后续中间件或路由逻辑卡住，连接无法释放帧调度权 - 响应体过大（如 >1MB JSON）且一次性
w.Write(buf)，整个流被占满，其他并发请求的帧只能排队 - 中间件（如日志）读取了
r.Body但没用r.Body = ioutil.NopCloser(bytes.NewReader(data))还原，下游 Handler 拿不到 body，静默失败
解决方法很直接：对大响应体用 io.Copy(w, file) 或分块 io.CopyN；所有读 body 的中间件必须还原；加 context.WithTimeout 防止单个 handler 拖垮整条连接。
最易被忽略的一点：HTTP/2 的性能优势高度依赖客户端连接复用。如果你用 http.Client 做内部调用，却没全局复用它，每个请求都新建连接，那 HTTP/2 就退化成多个 HTTP/1.1 了。
