记一次由「HTTP/2流优先级未生效」引发的排查
在优化Web性能时，HTTP/2的流优先级（Stream Priority）本应是提升资源加载效率的利器，但某次上线后，我们却发现关键CSS和JS文件的加载顺序依然混乱。本文记录这次排查的全过程，揭示优先级失效背后的真相。
**现象与预期不符**
根据HTTP/2协议，客户端可通过优先级树（Priority Tree）声明资源依赖关系。我们为关键资源设置了高权重（如weight=256），但实际抓包发现，浏览器仍以默认顺序加载。Chrome的DevTools中“Priority”一栏显示部分资源被错误标记为“Low”，与代码配置明显矛盾。
**抓包分析优先级帧**
通过Wireshark捕获的HTTP/2流量，我们定位到客户端确实发送了带有优先级参数的HEADERS帧，但服务端响应流（Stream）时未按预期调整传输顺序。进一步对比RFC 7540标准，发现服务端实现存在缺陷：它仅解析了依赖关系（Stream Dependency），却忽略了权重（Weight）字段的逻辑处理。
**服务端配置陷阱**
排查Nginx配置时，一个隐藏参数浮出水面：`http2_max_concurrent_streams`的默认值（128）导致高并发时优先级队列被挤压。反向代理层的旧版HTTP/2模块未启用动态优先级调整功能。升级至OpenSSL 1.1.1并调整`http2_recv_buffer_size`后，权重分配开始生效。
**浏览器策略干扰**
令人意外的是，部分浏览器（如Firefox）会基于资源类型覆盖开发者设定的优先级。例如，字体文件始终被赋予最高级，而异步JS则被降权。通过` rel="preload">`显式声明并结合`fetchpriority="high"`属性，最终绕过浏览器的内置规则。
**总结与反思**
此次排查揭示了HTTP/2优先级机制的复杂性：它需要服务端、客户端、中间件三方的协同支持。未来在性能优化中，我们将通过标准化测试套件（如h2spec）提前验证协议兼容性，避免将理论优势葬送在实现细节中。