Go 的 http.Server 默认不支持 HTTP/2 服务器推送，因 http.Pusher 接口自 Go 1.8 起为空实现，Go 1.22 中已被移除；根本原因是 net/http 将 HTTP/2 完全交由 crypto/tls 协商，不参与帧级控制。
Go 的 http.Server 默认不支持 HTTP/2 服务器推送
HTTP/2 推送（Server Push）在 Go 标准库中从未被实现，http.Pusher 接口虽存在，但自 Go 1.8 引入起就始终是空实现（返回 http.ErrNotSupported），且在 Go 1.22 中已被正式移除。这意味着：任何依赖 Pusher 的代码在新版 Go 中会直接 panic 或编译失败。
根本原因在于 Go 的 net/http 包选择将 HTTP/2 实现完全交由底层 TLS 层（即 crypto/tls）协商，而自身不参与帧级控制（如 PUSH_PROMISE 帧的构造与发送）。这不是遗漏，而是有意为之的设计取舍——优先保证安全、稳定和协议兼容性，而非暴露低层推送能力。
为什么不能用 ResponseWriter.(http.Pusher) 判断或调用
旧文档或示例中常见的写法：if p, ok := w.(http.Pusher); ok { p.Push(...) }，在 Go ≥1.22 下会因 http.Pusher 类型不存在而无法编译；在 Go 1.8–1.21 中则总是进入 else 分支或返回错误。
-
http.Pusher是一个未被任何标准ResponseWriter实现的接口 - 即使通过
httptest.ResponseRecorder或第三方中间件“模拟”该接口，也无法触发真实推送——底层 TLS 连接根本不接收或处理PUSH_PROMISE - 试图用反射强行注入或 patch
http.serverConn内部状态属于未定义行为，极易导致连接崩溃或数据错乱
替代方案：用 Link 头 + 浏览器自主预加载
现代浏览器（Chrome、Firefox、Safari）支持解析响应头中的 Link 字段，并据此提前发起资源请求。这虽非严格意义上的服务器推送（无 PUSH_PROMISE 帧），但在效果上接近，且更可控、可调试、不依赖 HTTP/2 底层支持。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操只需在 handler 中设置响应头：
w.Header().Set("Link", `</style.css>; rel=preload; as=style, </app.js>; rel=preload; as=script`)
注意要点：
-
rel=preload是关键，不是rel=push（后者无效） -
as=参数必须准确（如style、script、font），否则可能被忽略或降级为普通 fetch - 路径需为绝对路径（以
/开头），相对路径不会被识别 - 该机制在 HTTP/1.1 和 HTTP/2 下均有效，不增加协议依赖
真·推送需求强烈时，只能换技术栈
如果业务场景确实强依赖服务端主动推送（例如实时仪表盘动态下发子资源、规避首屏关键路径延迟），Go 标准库无法满足。可行路径只有：
- 改用支持推送的反向代理（如
nginx配置http2_push），让 Go 后端只负责生成 Link 头，由 nginx 解析并转换为真实 PUSH_PROMISE - 切换到明确支持推送的 HTTP 库，如
quic-go（基于 QUIC 实现 HTTP/3，含推送支持），但需客户端也支持 HTTP/3 - 放弃推送，改用更健壮的策略：HTTP/2 多路复用 + 资源内联（critical CSS/JS）+ Service Worker 缓存预热
别在 Go 的 net/http 上尝试 hack 推送逻辑——它从设计上就拒绝你这么做，而且越深挖越容易掉进 TLS 连接状态不一致的坑里。
