Go 的 http.Server 默认且明确禁用 HTTP/2 Push 功能，因其实用性差、易滥用且浏览器已普遍弃用；唯一启用方式是弃用 net/http，改用 golang.org/x/net/http2 手动构建 http2.Server 并调用 Pusher 接口，但需 TLS 且兼容性极差。
Go 的 http.Server 默认不支持 HTTP/2 Push
HTTP/2 Push 是服务端主动向客户端发送资源的能力，但 Go 标准库从 1.8 开始虽支持 HTTP/2，却**明确禁用了 Push 功能**——http.ResponseWriter.Push 方法始终返回 http.ErrNotSupported。
原因很实在：Push 在实践中容易滥用，导致带宽浪费、缓存失效、与浏览器预加载逻辑冲突；Go 团队选择“不提供默认开关”，而非留一个半成品接口。
- 即使你用
http2.ConfigureServer显式启用 HTTP/2，Push依然不可用 - 所有基于
net/http的常规服务（包括http.ListenAndServeTLS）都受此限制 - 不是配置遗漏，是标准库设计上就移除了该能力
想用 Push？只能换底层或绕过 net/http
目前唯一可行路径是脱离 net/http 的抽象，直接操作 HTTP/2 连接帧。主流做法是用 golang.org/x/net/http2 手动构造 http2.Server，并在 Handler 中拿到 *http2.ResponseWriter（它实现了 Pusher 接口）。
注意：这不是“开启某个 flag”，而是重写服务启动逻辑，且必须使用 TLS（HTTP/2 Push 不在明文 h2c 中支持）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须用
http2.Server替代http.Server，并传入自定义Handler -
Push调用需在响应头写出前完成，否则会报http2: invalid push after headers sent - 客户端必须是支持 Push 的浏览器（Chrome 94+ 已默认禁用，Firefox 早已移除），实际兼容性极差
// 示例片段：仅示意 Push 调用位置
func handler(w http.ResponseWriter, r *http.Request) {
if pusher, ok := w.(http.Pusher); ok {
pusher.Push("/style.css", &http.PushOptions{})
}
// ...后续写响应体
}
Push 的替代方案比强行启用更可靠
现代前端工程中，真正需要的往往不是 Push 本身，而是“让关键资源更快到达”。而 Push 的收益已被多种更可控的方式覆盖：
-
<link rel="preload">：由 HTML 主动声明，浏览器完全掌控调度优先级 - HTTP/2 多路复用 + 服务端资源内联（如 critical CSS）：减少请求数，避免 Push 的竞态问题
- Service Worker 缓存策略：对静态资源做细粒度控制，比服务端盲推更精准
- CDN 的 origin hint 或 Edge Side Includes（ESI）：在边缘层做资源组装，不依赖客户端 Push 支持
尤其要注意：Push 无法按用户角色、设备类型或网络条件动态决策，而 preload 可以通过服务端模板或 JS 动态注入。
如果真要测 Push，别在生产环境试
本地调试时，可用 curl --http2 -v https://localhost:8080 观察是否有 PUSH_PROMISE 帧，但结果意义有限——Chrome DevTools Network 面板已不显示 Push 资源，fetch() 和 XMLHttpRequest 也收不到 Push 来的响应。
- Node.js 的
http2模块仍保留 Push API，但同样面临浏览器弃用现实 - Go 生态里没有成熟封装 Push 的第三方 Web 框架，硬上等于自己维护 HTTP/2 流生命周期
- 一旦 TLS 证书配置错（比如用自签名但未加到系统信任链），整个 HTTP/2 连接会降级失败，Push 更无从谈起
Push 是个技术上可行、但生态和实践上已基本废弃的通道。真正卡住交付的，从来不是“能不能推”，而是“推什么、何时推、推给谁”——这些事，标准库故意没管，是有道理的。
