Go 1.22 起标准库彻底移除 HTTP/2 Server Push 支持，调用 http.Pusher 会 panic；浏览器自 Chrome 96+ 等已全面禁用，IETF 亦将其从规范中移除；应改用 Link: rel=preload 等现代替代方案。
Go 语言里不能用 http.Pusher 做 Server Push —— 不是配置不对，是标准库从 Go 1.22 起已彻底移除该能力，调用直接 panic。
为什么 w.(http.Pusher) 总是失败或 panic
这不是类型断言写错了，也不是 TLS 没配好。Go 标准库自 1.22 版本起，ResponseWriter.Push 方法内部直接返回 "http: no Push support" 并触发 panic。此前版本虽保留接口，但实际行为已被浏览器厂商废弃：Chrome 96+、Firefox 97+、Safari 15.4+ 全面禁用 HTTP/2 Push，IETF 也已将其从 HTTP/2 规范中移出。
常见错误现象包括：
-
panic: interface conversion: http.ResponseWriter is *http.response not http.Pusher（类型断言失败） - 静默忽略
Push()调用，无日志、无错误、浏览器收不到任何推送流 - 即使手动用
golang.org/x/net/http2构建http2.Server，也无法绕过浏览器端拦截
http2.ConfigureServer 和 TLS 配置根本没用
网上很多教程让你调用 http2.ConfigureServer(server, nil) 或设置 TLSConfig.NextProtos = []string{"h2"}，这些操作对启用 Push 完全无效。原因很明确：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
http2.ConfigureServer只影响 ALPN 协商和连接复用，不恢复已被移除的 Push 逻辑 - TLS 是 HTTP/2 的强制前提，但只是“能跑 h2”的必要条件，不是“能 Push”的充分条件
- 自签名证书在本地测试时可能让连接成功，但 Chrome 会拒绝推送（即使连接显示 h2），因缺少信任链校验
验证是否真用了 HTTP/2？看 r.Proto 是 HTTP/2.0，或用 curl -v --http2 https://localhost:8443/ --insecure 确认 ALPN offering h2 —— 但这和 Push 无关。
替代方案比硬扛 Push 更可靠
现代前端实践中，Link 头 preload 已成为事实标准，它由浏览器统一调度，不干扰缓存、不触发竞态、兼容性远超 Push：
- 在 handler 中写：
w.Header().Set("Link", `</style.css>; rel=preload; as=style`) - 资源路径必须绝对（如
/style.css），且需确保该路径能被当前路由处理并返回 200 - 相比 Push，preload 不要求 TLS 连接处于特定阶段，可在任意时机写入 header（只要未 flush）
- Webpack/Vite 构建产物带 hash？用模板注入真实路径，别硬编码
Push("/app.a1b2c3.js")
如果真需要服务端主动下发资源，优先考虑内联关键 CSS/JS，或用 <script async src="..."> + CDN 缓存策略 —— 这些方案稳定、可测、不依赖客户端玄学支持。
别在 http.Pusher 上浪费时间。它不是“还没配对”，而是“已下线”。真正的复杂点在于：你得重新设计资源加载时序，把原来指望 Push 解决的问题，拆解成 preload、预连接、缓存策略和构建优化的组合动作。
