HTTP/2服务端推送仅支持HTTPS+HTTP/2，需客户端ALPN协商"h2"且证书可信；Push()必须在WriteHeader()前调用，并通过w.(http.Pusher)断言；单请求推送不宜超3个关键资源，跨域或微服务间无效。
HTTP/2服务端推送必须走TLS，且客户端要支持
Go的net/http包对服务端推送（Server Push）有硬性限制：只在HTTPS + HTTP/2环境下生效，http.ListenAndServe完全不支持。即使你启用了TLS，若客户端（比如curl或浏览器）不支持ALPN协商中的"h2"，或者证书被拒绝（如自签名未用mkcert信任），推送会静默失败——既不报错，也不发送。
验证是否真正启用推送：curl -v --http2 https://localhost:8443/，观察响应头是否有push: 1或stream ID相关的PUSH_PROMISE帧；
浏览器开发者工具的Network面板中，查看资源请求的Protocol列是否为h2，并确认推送资源出现在“Initiator”列为push的条目里。
- 别用
http.ListenAndServe启动，必须用http.ListenAndServeTLS - 证书必须可信：Chrome/Firefox会直接拦截非CA签发的证书，导致降级到HTTP/1.1
- 服务端推送不是“主动发”，而是对客户端已发出请求的预判响应——它依赖于客户端明确声明支持
SETTINGS_ENABLE_PUSH=1，而现代浏览器默认开启，但某些gRPC-Web客户端或旧版curl可能关闭
Push操作必须在WriteHeader前调用
Go标准库的ResponseWriter对推送有严格时序要求：所有Push()调用必须发生在WriteHeader()或首次Write()之前。一旦响应体开始写入，连接状态已锁定，再调用Push()会返回http.ErrNotSupported错误，且不会panic，容易被忽略。
典型错误写法：
w.WriteHeader(200)
w.Write([]byte("ok"))
w.Push("/style.css", &http.PushOptions{}) // ❌ 失败，返回ErrNotSupported
正确顺序：
if pusher, ok := w.(http.Pusher); ok {
pusher.Push("/style.css", &http.PushOptions{})
pusher.Push("/script.js", &http.PushOptions{})
}
w.WriteHeader(200)
w.Write([]byte("ok")) // ✅
- 务必先做类型断言
w.(http.Pusher)，不是所有ResponseWriter都支持推送（比如某些中间件包装器可能剥离该能力） -
PushOptions中可设Method和Header，但多数场景用默认值即可；不要试图推送POST资源，浏览器只缓存GET响应 - 推送路径必须是绝对路径（如
"/assets/logo.png"），相对路径会被忽略
多路复用下推送与并发请求共享连接，但流数受服务端限制
HTTP/2的多路复用让推送和主响应共用同一TCP连接，但每个连接承载的并发流（stream）数量由Settings.MaxConcurrentStreams控制，默认是100。如果一个请求触发5次Push()，加上主响应本身，就占掉6个流——高并发下容易打满配额，新请求会被阻塞在队列里，表现像延迟飙升。
调整方式不是改代码，而是通过http.Server的TLSConfig间接影响：
- Go 1.19+ 默认启用HTTP/2，无需额外导入
golang.org/x/net/http2 - 若需调大流上限，得在
TLSConfig里设置NextProtos并手动注册http2.ConfigureTransport（仅客户端）；服务端无法直接配置MaxConcurrentStreams，它由对方SETTINGS帧协商决定 - 更实际的做法：限制单次请求的推送数量（≤3个关键资源），避免“全量推送”；对非首屏资源改用懒加载或preload link
- 注意：推送资源仍需符合同源策略，跨域推送会被浏览器丢弃
微服务间推送意义有限，优先考虑gRPC或消息队列
服务端推送本质是“从服务端向浏览器预加载静态资源”，在BFF或网关层有意义；但在Go微服务之间（比如Service A调用Service B），HTTP/2多路复用已由http.Client自动管理，Push()不仅不被支持，而且毫无用途——没有浏览器缓存机制，也没有UI渲染上下文。
如果你的目标是“提升微服务通信效率”，真正该做的是：
- 复用
http.Client，确保Transport.MaxIdleConnsPerHost ≥ 100 - 禁用
gzip中间件（尤其对流式响应如SSE、gRPC-Web） - 用
context.WithTimeout控制下游调用，防止一个慢请求拖垮整条连接上的其他流 - 大响应体用
io.Copy分块写，避免阻塞当前流导致其他并发流等待
服务端推送不是性能银弹，它只在特定前端优化场景下有效；把它塞进微服务调用链，反而增加调试复杂度和失败面。
