登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go教程

Go HTTP/2 服务端推送接口怎样判断是否可用

来源:17golang原创

时间:2026-10-17 16:18:09 461浏览 收藏

我在一次同时兼容 HTTP/1.1 和 HTTP/2 的页面服务里遇到过一个容易误判的问题:请求使用 HTTP/2,并不等于当前响应一定支持服务端推送。Go 的稳妥写法是先观察 r.ProtoMajor,再对 http.ResponseWriter 做 http.Pusher 接口断言,最后把 Push 的返回错误当成真正的能力结果。

官方文档:https://pkg.go.dev/net/http

判断顺序可以记成“协议只做观察,接口决定能不能调用,错误决定这一次是否成功”。无论推送是否可用,主请求都应该继续返回完整页面或资源引用。
  • 触发信号:同一个处理器需要兼容 HTTP/1.1、HTTP/2 或中间层禁用推送的情况。
  • 快速判断:先看 r.ProtoMajor,再检查 w.(http.Pusher)。
  • 处理原则:在写出页面数据前尝试 Push,失败就记录原因并走普通响应。

为什么 HTTP/2 请求仍然不代表可以推送

在 Go 服务端,请求的 ProtoMajor == 2 说明这次请求使用 HTTP/2,但它不是对响应写入器能力的承诺。Go 官方文档把服务端推送能力放在 http.Pusher 接口上:只有当前 ResponseWriter 实现了这个接口,处理器才有机会发起推送。

更实际的原因是,底层连接或客户端可能关闭了推送能力。官方接口说明明确指出,Push 在客户端禁用推送或底层连接不支持时会返回 http.ErrNotSupported。因此,协议字段适合写日志和指标,接口断言与返回错误才适合控制分支。

Go HTTP请求协议、ResponseWriter与Pusher能力边界的静态结构说明图
图1:静态结构说明图,展示请求协议、响应写入器和 Pusher 能力之间的边界;它不是运行截图或执行证据。

在发送页面数据前完成一次能力判断

推送应该发生在主响应写出可能触发资源请求的数据之前。下面的处理器把能力判断、推送调用和普通页面响应放在同一处,便于值班时快速定位。

package main

import (
	"errors"
	"log"
	"net/http"
)

func home(w http.ResponseWriter, r *http.Request) {
	// 协议字段只用于观察和记录,不能单独决定是否调用 Push。
	if r.ProtoMajor == 2 {
		log.Printf("request protocol=%s", r.Proto)
	}

	// 先做能力断言;HTTP/1.1 或不支持推送的写入器会走降级分支。
	pusher, ok := w.(http.Pusher)
	if ok {
		// 必须在写出页面内容前尝试推送,目标资源使用同一来源路径。
		err := pusher.Push("/static/app.js", nil)
		if err != nil {
			// ErrNotSupported 表示本次连接不能推送,普通响应仍要继续。
			if errors.Is(err, http.ErrNotSupported) {
				log.Printf("http push unavailable: %v", err)
			} else {
				// 其它错误保留日志,便于区分路径或连接层问题。
				log.Printf("http push failed: %v", err)
			}
		}
	}

	// 无论推送是否成功,都返回可独立加载资源的页面。
	w.Header().Set("Content-Type", "text/html; charset=utf-8")
	w.WriteHeader(http.StatusOK)
	_, _ = w.Write([]byte("

首页

")) } func main() { // 用标准库路由注册处理器;生产环境还应由部署层提供 HTTPS/HTTP2 配置。 http.HandleFunc("/", home) log.Fatal(http.ListenAndServeTLS(":8443", "server.crt", "server.key", nil)) }

这段代码的关键点不是“只在 HTTP/2 时推送”,而是把三个结果分开:协议用于观察,接口断言用于获得调用入口,Push 错误用于确认本次是否真的可用。资源仍然写在 HTML 中,所以浏览器或代理不接受推送时,页面不会因为缺少预加载资源而失败。

Go Pusher调用与普通HTML资源回退关系的静态结构说明图
图2:静态关系说明图,展示 Pusher 调用失败后仍回到 HTML 资源引用的降级边界;它不是运行截图或执行证据。

推送路径、时序和回滚怎么确认

值班时可以按下面的顺序检查,不需要把推送失败当成主请求故障:

  1. 看协议:记录 r.Proto,确认请求是否真的经过 HTTP/2;这一步只用于定位入口和中间层。
  2. 看能力:检查接口断言是否成功;断言失败时不要强行转换类型,也不要把普通 ResponseWriter 包装成“支持推送”。
  3. 看调用时机:把 Push 放在第一次写页面数据之前。官方说明还提醒,推送会在单独 goroutine 中运行,到达顺序不是确定的,依赖顺序的业务逻辑不要放在这里。
  4. 看目标边界:优先使用同源绝对路径,例如 /static/app.js。PushOptions 的方法只能是 GET 或 HEAD,不要把业务 POST 当成推送目标。
  5. 准备回滚:保留普通 HTML 引用作为默认路径;如果推送错误日志持续增加,可以关闭推送尝试而不修改页面资源加载逻辑。

复盘项:把协议版本、接口断言结果、Push 错误类型和目标路径作为同一组字段记录。这样能区分“没有 HTTP/2”“写入器不支持”“客户端禁用推送”和“目标路径不合规”,避免只看到一个空白的“推送失败”。

常见问题

只判断 r.ProtoMajor == 2 可以吗?

不建议。它只能说明请求协议,不能证明当前写入器实现了 http.Pusher,也不能排除客户端禁用推送。至少还要做接口断言,并处理 Push 返回的错误。

Push 返回 ErrNotSupported 后要返回错误页吗?

通常不需要。它表示本次推送不可用,主响应仍应包含正常的资源引用;只有页面本身无法独立工作时,才需要按业务协议处理主请求错误。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>