Go 1.8+ 默认支持 HTTP/2，但必须使用 TLS（http.ListenAndServeTLS 或配置 TLSConfig），纯 HTTP 始终为 HTTP/1.1；确认方式为 Chrome DevTools 查 Protocol 显示 h2 或 curl -v --http2 观察 ALPN 协商结果。
Go 1.8+ 默认支持 HTTP/2，但需要 TLS
Go 的 http.Server 在 1.8 起自动启用 HTTP/2，前提是使用 TLS 启动——纯 HTTP（http.ListenAndServe）永远走 HTTP/1.1，怎么配都升不了级。
- 必须用
http.ListenAndServeTLS或配置http.Server.TLSConfig后调用server.ListenAndServeTLS - 自签名证书可用
generate_cert.go工具生成，但浏览器会报错；开发时加--unsafely-treat-insecure-origin-as-secure="https://localhost:8080" --user-data-dir=/tmp/test启动 Chrome 可临时绕过 - HTTP/2 不支持 HTTP/1.1 的 Upgrade 协议切换，所以
http.ListenAndServe+h2c（明文 HTTP/2）需额外处理，不推荐用于生产
如何确认服务真正在用 HTTP/2
别信文档，看实际协商结果。Chrome DevTools 的 Network → Headers → “Protocol” 列显示 h2 才算数；curl 要加 -v 看 ALPN 协商日志。
- curl 命令：
curl -v --http2 https://localhost:8080，若返回中出现ALPN, offering h2和SSL connection using TLSv1.2 / ECDHE...且没报错，基本成功 - 服务端加日志：在
http.HandlerFunc里打印r.Proto，HTTP/2 请求会是HTTP/2.0，不是HTTP/1.1 - 注意：某些反向代理（如 Nginx 默认配置）会终止 TLS 并降级回 HTTP/1.1 转发，此时后端 Go 服务看到的仍是 HTTP/1.1
HTTP/2 Server Push 怎么写，为什么很少用
Go 标准库支持 Pusher 接口，但只在 http.ResponseWriter 实现了 push 方法，且仅当底层连接是 HTTP/2 且客户端声明支持时才生效。
- 用法示例：
pusher, ok := w.(http.Pusher); if ok { pusher.Push("/style.css", nil) } - 问题在于：现代浏览器（Chrome 96+、Firefox 90+）已废弃
Push，Service Worker + HTTP Cache 更可控；Go 1.22 仍保留接口，但实际 push 行为可能被忽略 - 如果硬要用，确保资源路径是绝对路径（
/assets/logo.png），相对路径或外部域名会直接 panic
常见错误：listen tcp :443: bind: permission denied 或 x509: certificate signed by unknown authority
前者是端口权限问题，后者是证书链或域名不匹配——这两类错误在 HTTP/2 场景下更敏感，因为 TLS 是强制前提。
-
bind: permission denied：Linux/macOS 下非 root 用户不能绑定 1–1023 端口；改用:8443或用sudo setcap 'cap_net_bind_service=+ep' ./myserver -
x509: certificate signed by unknown authority：自签证书没被系统信任；开发时可传&http.Client{Transport: &http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true}}}，但仅限测试 - 证书 CN 或 SAN 必须包含请求域名，比如用
https://localhost:8080测试，证书就得有localhost；用 IP 访问（https://127.0.0.1）则证书必须含该 IP，否则握手失败
HTTP/2 的坑不在 Go 代码本身，而在 TLS 握手那几毫秒里埋的细节：证书、ALPN、SNI、代理透传——漏一个，就退回 HTTP/1.1，还查不出为什么。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
