Go net/http 怎样接收 HTTP2 客户端优先级信号

Go 1.27 的 net/http 服务端已经可以接收 HTTP/2 客户端按照 RFC 9218 发送的优先级信号，并由内置 HTTP/2 调度逻辑参与请求服务顺序。最容易误解的一点是：这里的“接收”不是在 Handler 里拿到一个公开的优先级字段，而是服务端内部根据配置决定是否尊重这些信号。默认情况下保留客户端优先级；只有明确设置 Server.DisableClientPriority 为 true，才关闭这项处理。

官方地址：https://go.dev/

本文只讨论 Go 1.27 标准库、HTTP/2 服务端和默认写调度器。若请求实际协商成 HTTP/1，或服务端使用自定义 HTTP/2 写调度器，下面的结论不能直接套用。

先确认请求真的走到了 HTTP/2 服务端

排查这类问题时，第一层不是修改优先级开关，而是确认协议路径。Go 的服务端在 HTTPS 场景下通常会自动启用 HTTP/2；但自定义 TLS 连接、协议集合或 TLSNextProto 可能改变默认行为。客户端信号只有在 HTTP/2 连接上才有意义，HTTP/1 请求不会触发这套调度。

可以先把观测重点放在请求协议和服务端启动配置上。不要因为客户端使用了 HTTPS，就直接推断每个请求都是 HTTP/2；代理、ALPN 协商和服务端协议配置都可能让实际协议不同。

“接收信号”不等于 Handler 能读取优先级字段

net/http 把 RFC 9218 的客户端优先级处理放在 HTTP/2 服务端调度层。业务处理函数仍然通过 http.Request 接收方法、URL、头部和请求体，但标准公开 API 没有一个让 Handler 直接读取 HTTP/2 优先级树或增量优先级值的字段。

因此，下面两种说法要分开：一是“服务端能接收并尊重客户端信号”，它描述的是协议实现和调度器行为；二是“业务代码能读取客户端优先级并据此改写业务逻辑”，这不是 net/http 的公开承诺。若文章把两者混在一起，通常会出现找不到字段、把普通 Header 当成调度证据的问题。

Go 1.27 发布说明将这项变化描述为 HTTP/2 服务端开始接受客户端优先级信号；Server 文档进一步说明了开关的作用范围。官方说明见 Go 1.27 net/http 变更 和 net/http.Server。

DisableClientPriority 的三个判断条件

这个字段不是“是否开启 HTTP/2”的总开关。读取它时应同时问三个问题：

• 当前连接是不是 HTTP/2；HTTP/1 请求不受它影响。
• 服务端是否使用标准 HTTP/2 写调度器；如果配置了自定义写调度器，该字段可能是 no-op。
• 字段值是否为 true；为 true 时请求按不带优先级的 round-robin 方式服务。

零值为 false，表示不主动禁用客户端优先级，也就是允许内置 HTTP/2 调度器尊重 RFC 9218 信号。若团队希望行为更显式，可以在构造 http.Server 时写出 DisableClientPriority: false；若要恢复不考虑优先级的轮转服务，则设置为 true。

用最小配置保留或关闭客户端优先级

下面的配置只展示开关所在位置。它假设通过 TLS 启动标准 http.Server，没有替换 HTTP/2 写调度器；证书文件、实际流量和客户端协商不在本文中执行。

package main

import (
    "log"
    "net/http"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        // Handler 负责业务响应，不把 HTTP/2 优先级当成公开请求字段读取。
        w.WriteHeader(http.StatusNoContent)
    })

    srv := &http.Server{
        Addr:    ":8443",
        Handler: mux,
        // false 保留标准 HTTP/2 服务端对客户端优先级的处理。
        DisableClientPriority: false,
    }

    // HTTPS 下由标准 Server 完成协议协商；证书路径按部署环境替换。
    log.Fatal(srv.ListenAndServeTLS("server.crt", "server.key"))
}

如果业务验证后发现客户端优先级会让某类流量不符合既有调度预期，可以只改这一项：

srv := &http.Server{
    Addr: ":8443",
    // true 表示忽略客户端优先级，使用不带优先级的轮转服务方式。
    DisableClientPriority: true,
}

不要把 true 当作“修复 HTTP/2 没启用”的办法；它只影响客户端优先级是否被标准调度器尊重。也不要在每个请求处理函数里重复创建 Server，Server 应在服务生命周期内保持稳定，并在配置变更时重新部署或按项目的生命周期策略重建。

反向检查：配置生效了吗

遇到“设置了但看不出变化”时，可按三层排查：先确认请求的实际协议是 HTTP/2，再确认没有通过 TLSNextProto 或其他配置绕开标准 HTTP/2 路径，最后确认没有自定义写调度器。三项都满足后，再比较 DisableClientPriority 的值。

这里的“比较”应使用受控客户端和可重复的服务场景，而不是把某一次响应先后直接当成优先级证据。并发量、响应大小、服务端处理时间和网络拥塞都可能改变观察结果。标准库文档明确给出的是生效条件和语义，不是某个业务的固定吞吐比例。

Go 旧版本也能直接使用这个字段吗？

不要只看源码是否能编译。本文讨论的是 Go 1.27 引入的 HTTP/2 服务端客户端优先级行为，升级前应以对应版本的 net/http.Server 文档为准。

能在 Handler 里读取 RFC 9218 的优先级值吗？

标准 net/http 的公开 Request API 没有承诺提供这样的字段。应把它理解为 HTTP/2 调度层行为，而不是业务请求元数据。

设置 DisableClientPriority=true 会关闭 HTTP/2 吗？

不会。它只表示标准 HTTP/2 服务端不按客户端优先级进行调度，HTTP/2 是否启用仍由协议协商和服务端配置决定。

相关官方参考：Go net/http Server 源码注释、Go net/http HTTP/2 配置实现、Go 1.27.3 Server 文档。本文代码、表格与图示均为原创教学材料。