Go net/http HTTP2 客户端优先级让请求顺序变化怎么办

如果升级到 Go 1.27 后，Go net/http 的 HTTP/2 服务端不再按原来的顺序处理并发请求，优先检查客户端是否发送了 RFC 9218 定义的优先级信号。Go 1.27 的 HTTP/2 服务端默认会参考这些信号；如果业务更依赖旧的轮询行为，可以在 http.Server 中设置 DisableClientPriority: true。

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

这个字段解决的是 HTTP/2 服务端如何安排流的写出，不是客户端 API 的“请求排队开关”，也不能替代业务层的严格顺序控制。

• Go 1.27：HTTP/2 服务端开始接受并参考客户端优先级。
• 兼容设置：DisableClientPriority: true 恢复不按优先级的轮询服务方式。
• 生效边界：只对 HTTP/2、且没有自定义 HTTP/2 写调度器的服务端配置生效。

为什么升级后 HTTP/2 请求顺序会变化

HTTP/2 把多个请求流复用在同一条连接上，服务端不必等一个响应完成后才处理下一个流。过去的 Go 服务端可以用近似轮询的方式推进这些流；Go 1.27 的发布说明明确提到，HTTP/2 服务端现在会接受 RFC 9218 中定义的客户端优先级信号，并优先服务优先级更高的流。

因此，客户端同时发起多个请求时，看到响应先后变化并不一定表示网络乱序、连接复用失效或 Handler 被错误调用。变化可能来自流之间新增的调度信息。这里的“优先级”是 HTTP/2 流调度线索，不等于服务器会替业务判断哪个请求必须先完成，也不等于客户端发送调用的先后被改写。

DisableClientPriority 到底关闭了什么

DisableClientPriority 是 http.Server 的服务端字段。它设为 true 后，服务端对 HTTP/2 请求采用不考虑客户端优先级的轮询方式。文档同时给出了两个限制：这个字段只有在使用 HTTP/2 时才有意义；如果 HTTP/2 服务端定义了自定义写调度器，它就是空操作。

这意味着它不是 http.Transport 的客户端配置，也不会阻止客户端发送优先级信息。它只改变 Go 标准库服务端如何利用这些信息。若请求实际上走的是 HTTP/1，或者服务端没有启用 HTTP/2，这个字段不能解释请求顺序变化。

在 http.Server 中保留旧的轮询行为

如果现有系统把“多个响应大致轮流写出”当作兼容性假设，可以把这个选择直接写进服务端初始化。下面的示例只展示配置关系；证书文件和处理器应替换成项目自己的部署配置。

package main

import (
    "log"
    "net/http"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/api/task", func(w http.ResponseWriter, r *http.Request) {
        // 处理器只负责当前请求，不能把传输层调度当成业务排序。
        w.WriteHeader(http.StatusAccepted)
        _, _ = w.Write([]byte("accepted"))
    })

    srv := &http.Server{
        Addr: ":8443",
        Handler: mux,
        // true 让 HTTP/2 服务端不按客户端优先级调度流。
        DisableClientPriority: true,
    }

    // 使用 TLS 启动 HTTP/2；证书路径应来自部署配置。
    if err := srv.ListenAndServeTLS("server.crt", "server.key"); err != nil && err != http.ErrServerClosed {
        // 启动或监听失败时保留原始错误，便于定位配置问题。
        log.Fatal(err)
    }
}

这个设置表达的是一个兼容性取舍：服务端仍然可以同时处理多个 HTTP/2 流，但不再根据客户端优先级区分服务顺序。它不会把并发请求变成串行队列，也不会让响应到达顺序成为稳定的业务协议。

不要把传输层调度当成业务顺序

如果业务要求“创建必须早于更新”“批次号小的结果必须先落库”，仅仅关闭客户端优先级仍然不够。HTTP/2 仍然允许并发流，Handler 也可能在不同 goroutine 中执行；客户端读取响应、代理转发和服务端写出都会影响观察到的先后。

严格顺序应该由应用协议表达，例如为任务携带单调递增的序号，在服务端按序提交，或让后一个请求显式依赖前一个请求的确认。这样即使以后重新启用优先级调度，业务约束仍然成立。DisableClientPriority 更适合处理升级后的兼容差异，而不是承担事务编排职责。

请求顺序变化的排查清单

1. 确认协商出的协议确实是 HTTP/2，而不是把 HTTP/1 的连接池问题混进来。
2. 记录客户端是否发送了优先级信号，以及代理或网关是否修改了它。
3. 查看 Go 版本和服务端的 DisableClientPriority 值，确认是否使用了默认行为。
4. 确认是否存在自定义 HTTP/2 写调度器；存在时不要期待该字段改变调度结果。
5. 最后检查业务是否真的要求严格顺序；如果要求成立，应增加序号、依赖或服务端排队规则。

常见问题

设置 DisableClientPriority 后，HTTP/2 请求会严格按发送顺序完成吗？

不会。它只让标准库服务端不按客户端优先级进行流优先化，仍然保留 HTTP/2 多路复用和并发处理。网络、Handler 执行时间和客户端读取方式都可能改变完成先后。

客户端应该在哪里设置 DisableClientPriority？

不能在客户端的 http.Transport 中设置，因为该字段属于 http.Server。客户端可以影响自己发送的请求和优先级信号，但是否尊重这些信号由服务端调度策略决定。

自定义调度器存在时还要保留这个字段吗？

如果服务端确实使用了自定义 HTTP/2 写调度器，该字段按文档属于空操作。应直接检查自定义调度器的规则，并在它的配置或代码中表达需要的兼容策略。

参考：Go 1.27 Release Notes、net/http.Server、RFC 9218。