go的http.server默认不支持http/2优先级调度，既忽略客户端优先级信号，也不提供api设置响应流权重或依赖关系；实际可用方案仅有基于golang.org/x/net/http2手动构建自定义server。
Go 的 http.Server 默认不启用 HTTP/2 优先级调度
HTTP/2 流量优先级（stream priority）在 Go 标准库中长期处于“存在但不可控”状态：http.Server 虽然支持 HTTP/2（通过 TLS 自动升级），但完全忽略客户端发来的优先级信号，也不暴露任何接口去设置响应流的权重或依赖关系。这不是 bug，是设计取舍——Go 官方认为服务器端主动干预优先级容易引发复杂性，且多数场景下由客户端驱动更合理。
这意味着：即使你用 Chrome 发出带 priority 字段的请求，Go 服务端也只当它不存在；你也不能用 ResponseWriter 去“提升某个 JSON 接口的权重”。
- HTTP/2 优先级生效的前提是双方都参与调度，而 Go 的
net/http实现跳过了整个优先级树构建与依赖排序逻辑 - 如果你依赖优先级做资源抢占（比如首屏 HTML 必须比图片快），得换方案——比如用多个域名分流、或前置代理（如 Envoy）接管优先级
- Go 1.22+ 仍无 API 暴露
PriorityParam或类似字段；别在http.ServeMux或中间件里找钩子，它根本没留入口
想让 Go 服务响应 HTTP/2 优先级，唯一可行路径是绕过 net/http
标准库不行，就得自己拼协议层。目前只有两个实际可落地的选择：用 golang.org/x/net/http2 手动搭帧，或接入第三方 HTTP/2 库（如 quic-go 的 HTTP/2 支持，或 lucas-clemente/quic-go 衍生的轻量封装）。
最现实的是基于 x/net/http2 构建自定义 server：它提供了 http2.Server 类型，允许你在 FrameRead 钩子中解析 PRIORITY 帧，并在写响应时调用 Framer.WriteHeaders 传入 http2.PriorityParam。
立即学习“go语言免费学习笔记（深入）”；
- 必须禁用标准库的自动 HTTP/2 升级：
Server.TLSConfig.NextProtos = []string{"h2"}，且不能含"http/1.1" - 不能复用
http.HandlerFunc，因为优先级决策要发生在 headers 写入前，需自己管理 stream 生命周期 - 注意
PriorityParam中的StreamDep是其他 stream ID，不是请求 ID；搞错会导致依赖环或被对端拒绝
http2.PriorityParam 的权重值不是越大越优先
HTTP/2 权重是相对值，范围 1–256，但它的语义不是“分数”，而是“占比系数”。假设 A 流依赖 B，A 权重 16、B 权重 32，那 B 分到的带宽 ≈ 2× A；但如果 B 权重设为 256、A 设为 1，B 也不会独占全部——协议只保证比例，不保证绝对抢占。
- 权重为 0 是非法值，
golang.org/x/net/http2会 panic - 依赖关系（
StreamDep）必须指向已存在的 stream ID，否则对端可能直接 RST_STREAM - Chrome 和 curl 对权重变化的反应很慢，别指望实时看到“JS 加载变快了”；优先级主要影响多路复用下的帧调度顺序，不是带宽分配器
生产环境慎用自定义优先级逻辑
真正需要精细控制 HTTP/2 优先级的业务极少。绝大多数性能瓶颈不在协议层调度，而在 handler 执行时间、DB 查询、模板渲染这些地方。强行加优先级，反而容易掩盖真实问题。
- Go 的 goroutine 调度和 TCP 拥塞控制已经足够平滑，HTTP/2 优先级在大多数后端服务中收益趋近于零
- 一旦引入自定义
http2.Server，你就得自己处理流控（InitialWindowSize）、SETTINGS 帧协商、连接保活等细节，出错率陡增 - 如果上游有 CDN 或 LB（比如 Cloudflare、ALB），它们大概率已剥离或重写优先级帧——你费劲设的
PriorityParam可能根本传不到客户端
优先级不是开关，是整条链路的协同契约。单点改动，基本白忙。
