HTTP/2 协议与浏览器支持——这个话题我琢磨了挺久因为光看协议文档你根本感受不到它在真实浏览器里有多少门道。我做前端性能优化和站点架构改造也有六七年了踩过的坑能排一长串。年初给一个老项目做 HTTP/2 升级本以为改个服务端配置就能跑结果被浏览器那边的一堆细节折腾得够呛。这篇文章把我这次改造从头到尾的过程连同这几年积累的跨浏览器兼容性经验一起梳理出来。无论你是刚接触 HTTP/2 的开发者还是已经在用但偶尔被浏览器行为弄懵的运维应该都能找到点有用的东西。1. HTTP/2 到底解决了什么浏览器难题1.1 HTTP/1.1 时代的三个老毛病队头阻塞、连接数上限、头部冗余我们先从源头说起。HTTP/1.1 协议本身是在 1997 年定型的那时候网页就几十 KB一个页面三五张图根本没人想到十几年后一个首页能塞下上百个资源请求。HTTP/1.1 在浏览器里的表现有三个被吐槽了无数次的痛点第一个是队头阻塞。同一个连接上的请求必须排队前一个没响应完后一个就得等着。打个比方一条单车道只能一辆车走前面那辆要是抛锚了后面全堵死。浏览器层面虽然有多个连接可以并发但每个连接内部依然是串行的。第二个是连接数上限。为了限制单服务器资源占用HTTP/1.1 时代浏览器普遍限制对同一域名的并发连接数为 6 个左右。这直接催生了“域名分片”这种奇葩优化——把静态资源分散到多个子域名骗浏览器多开连接。这招有效但代价是额外的 DNS 查询、TCP 握手机制反而可能拖慢首屏。第三个是头部冗余。每次请求都要把 User-Agent、Cookie、Accept 这些同样的头部信息重发一遍一个页面几十上百个请求浪费的字节非常可观。虽然 gzip 能压缩头部但压缩开销和处理延迟一直都在。这三个问题叠加起来就是我在开头说的那个场景资源已经压缩过了也做了 CDN 加速但页面加载时间始终卡着下不去。当时的直觉是“资源没拆到位”但后来才意识到瓶颈根本不在压缩率上而在于协议本身一次只能处理有限请求的效率上限。1.2 HTTP/2 的四个核心机制二进制分帧、多路复用、HPACK、服务器推送HTTP/2 连根上的设计目标是解决上面那些问题而不仅仅是优化表面速度。它引入的几个机制每个都跟浏览器行为直接相关。二进制分帧层是整个协议的地基。HTTP/2 不再传纯文本格式而是把所有数据拆成一个个二进制帧每个帧属于某个“流”。这些帧在同一个 TCP 连接上发送到达后再按流头信息重组。这条设计直接解决了队头阻塞——请求和响应可以在一个连接上交错传输谁也不等谁。多路复用就是建立在这个分帧层之上的能力。浏览器不再受 6 连接限制只需要一条 TCP 连接就能同时发几十个请求、收几十个响应。数据像是并排在多车道上跑互不干扰。我改造完成后在 Network 面板里看瀑布图印象特别深之前那些排队、阻塞、等待的竖条几乎全没了所有资源几乎是平着一起下来的。HPACK 头部压缩是第三个大机制。HTTP/2 维护一张静态表加动态表把常见头部字段映射成整数索引配合 Huffman 编码压缩。Cookie 这类大头虽然第一次还要完整传但后续请求就能用索引引用头部体积整体能少掉一半以上。服务器推送则是最容易被误解的一项。服务端可以在客户端没主动请求的情况下预判它接下来会需要什么资源比如 CSS、图片主动推过来。想法很好——省去浏览器发现资源的往返时间。但后面我会细讲这个机制在真实浏览器里的表现远比文档描述复杂滥用会出事。1.3 为什么说协议设计必须跟浏览器配合才能生效这一点可能是很多人忽略的HTTP/2 的每一项能力最终都要靠浏览器来实现和暴露协议文档只是定义了一个理想模型实际能不能发挥作用要看浏览器这一侧的网络栈和页面加载流程怎么对待它。多路复用能不能跑满取决于浏览器对“关键请求优先级”的调度策略服务器推送要不要接受、接受多少也完全是浏览器说了算就连 HTTP/2 会话的建立本身都要依赖 TLS 握手中的 ALPN 扩展来协商。正因如此你在服务端开启了 HTTP/2并不能直接说明用户就享受到了 HTTP/2。只有当你确认浏览器端确实以 h2 协议完成了请求性能收益才真正落地。所以这篇文章不会只讲协议我更想把重心放在“浏览器支持”这四个字上——它们之间的沟壑才是工程问题密集爆发的地方。2. 浏览器对 HTTP/2 的支持地图别只看 Can I Use2.1 主流浏览器支持情况与版本线先把支持情况摆给你们看。每次聊 HTTP/2总有人拿一张“支持率 95%”的图表截图说事但实际项目里用户的浏览器环境往往比统计表差得多。浏览器首个完整支持 HTTP/2 的版本说明Chrome49早期版本通过 SPDY 过渡从 49 开始默认启用 h2Firefox4443–44 之间逐步改善 h2 稳定性44 起默认启用Safari9只支持基于 TLS 的 h2不支持明文 h2cEdge14基于 Chromium 内核的 Edge 与 Chrome 同步IE11不支持只支持 SPDY/3.1而且是 Win8.1/10 特定版本iOS Safari9 起支持10 以后表现稳定但旧版调度策略相对保守微信内置浏览器视系统内核而定Android 微信多使用 X5 内核iOS 走 WKWebView两者 H2 支持情况差距很大这个表格是我做项目时的底线参考。你会发现真正的难点不在“是否支持”而在“支持到什么程度”。很多浏览器号称支持 HTTP/2但在特定场景下的行为和别的浏览器完全不一样。后面我展开讲。2.2 老生常谈但常被忽略h2、h2c 和加密套件HTTP/2 有两个协议标识基于 TLS 的h2和明文传输的h2c。浏览器世界里基本只有h2真正存在——所有主流浏览器都不支持 h2c。所以如果你想省事搞个不装证书的 HTTP/2省省吧浏览器不会理你的。这里就有第一个容易踩坑的点h2 必须由 TLS 握手阶段的 ALPN 扩展协商出来。服务端不能简单地说“我支持 HTTP/2”还得在 TLS 握手时告诉浏览器“我可以提供 h2 协议”。同时浏览器对 TLS 版本和加密套件也有硬性要求。老版本 Chrome 和 Firefox 都曾拒绝过某些弱加密套件下的 h2 协商导致连接最终回落到 HTTP/1.1。我在实际项目里遇到过一台内网服务器证书还是 1024 位 RSATLS 1.0配置写完一测浏览器全部走 HTTP/1.1 加载。检查半天才发现是服务端虽然监听 443 并声明了http2但 TLS 握手根本没能完成 ALPN 协商。证书有效期、密钥长度、TLS 最低版本、加密套件列表每个环节都可能阻断 h2 协商。你可以在 Chrome 的chrome://net-internals里看到完整握手过程它会明确告诉你 ALPN 是否返回了 h2。2.3 快速检测当前页面是否真的走了 HTTP/2检测比很多人想象中简单但也很容易被误导。我惯用的几个方法方法一浏览器 Network 面板。Chrome DevTools 的 Network 面板协议列会显示h2。但注意面板默认可能没显示协议列需要右键表头勾选 Protocol。看到h2不代表所有资源都走了 h2——你需要把所有请求都刷一遍确认尤其要注意有没有资源走了http/1.1那通常意味着某个子资源服务器或者 CDN 节点没支持。方法二curl 直接查响应头。用curl -I --http2 https://example.com命令。如果返回头里能看到HTTP/2 200说明支持。但 curl 走的是自己的一套实现结果只能作为服务端支持情况的参考不能替代真实浏览器的检测。方法三抓包看 TLS 握手。要看完整协商过程Wireshark 抓 TLS 包最直接。过滤tls.handshake.alpn或tls.handshake.extensions_server_name能看到 ALPN 列表。这里可以看到服务端在握手时到底提供了哪些协议以及客户端选择了哪个。这个方法在排查“为什么这个浏览器没走 h2”时特别好用。3. 跨浏览器支持的设计与实现纸上协议和现实差距3.1 不同浏览器对多路复用的行为差异多路复用是 HTTP/2 最核心的能力但不同浏览器对“优先级”的处理方式差异极大。HTTP/2 规范里定义了流的优先级和依赖关系每个流可以带一个权重和依赖标识告诉服务端“哪个资源更重要”。规范归规范浏览器怎么设优先级、服务端是否理会权重完全是另一回事。Chrome 在优先级调度上比较激进它会把 CSS 和阻塞渲染的脚本放在最高优先级图片和异步脚本放低。Firefox 的实现也大体遵循规范但在流依赖的分配上跟 Chrome 不太一致。Safari 相对保守在某些版本里对低优先级流的处理会让大量图片加载延后。这些差异直接导致同一套 HTTP/2 服务部署后不同浏览器用户体验到的加载顺序完全不同。我做过一个对比同一个页面Chrome 下首屏渲染只用了 800ms但 Safari 上要 1.4 秒。当时一度以为是浏览器执行 JS 效率差异后来才发现是请求优先级排序不同Safari 把首屏需要的某张关键图排到了比较靠后的位置。即使协议层相同浏览器调度策略依然决定了最终性能表现。换句话说跨浏览器做 HTTP/2 优化不能只看服务端配置还要从资源加载顺序上考虑每个浏览器的脾气。3.2 服务器推送的浏览器“副作用”和滥用后果服务器推送在文档里描述得很理想实际却是最容易翻车的功能。几个真实里常见的坑第一个坑是Chrome 的“推送流计入内存缓存”的问题。Chrome 会把推送来的资源放入一个专属的内存缓存memory cache而不是磁盘缓存。这意味着每次关闭浏览器、甚至有时候刷新页面推送的资源就失效了又得重新拉一份。你本想省下往返时间结果反而增加了传输开销。第二个坑是Firefox 对推送流的接受策略相对随机。在某些场景下Firefox 会接受推送但忽略其优先级甚至限制并发推送流数量。比如你一口气推了 10 个资源Firefox 可能只接受前几个后面的全部拒绝客户端再重新发起正常请求。第三个坑最普遍推送了自己其实不需要的资源。一旦服务器主动推送了浏览器已缓存或不会用到的资源那就是纯粹的带宽浪费。我见过有项目把初始化 API 响应都做成推送结果用户每次打开页面都白白下载一大坨根本没用到的数据。我的建议是新项目优先不用服务器推送除非你能精确控制推送条件并能处理不同浏览器的异常行为。与其在推送的迷宫里绕不如把精力放在静态资源的缓存策略和关键请求的优先级优化上。如果实在要用请务必给推送资源设置正确的 cache-control 头并且只推高置信度的首屏资源。3.3 降级与回退设计让老浏览器过得舒服跨浏览器支持的根本原则不是“让所有浏览器都享受 HTTP/2”而是“让不支持 HTTP/2 的浏览器也能正常访问”。这看起来像废话但在实际工程里很容易反过来为了给新浏览器做极致优化反而把老浏览器体验弄砸了。HTTP/2 的降级路径是自动的——握手失败就会回落到 HTTP/1.1。但这不代表你可以什么都不管。因为 HTTP/2 和 HTTP/1.1 的优化策略是有冲突的。以资源合并为例HTTP/1.1 时代大家习惯把多个 JS/CSS 合并成一个大文件减少请求数但 HTTP/2 时代多路复用让“许多小请求”的开销变得很低反而拆分更细更利于缓存复用和按需加载。如果你站点只给新浏览器走拆分策略老浏览器访问时就傻眼了——几十个小文件请求在 6 连接的限制下全排起长队性能暴跌。所以我在项目里做了一套最简单的降级方案只在确认不支持 HTTP/2 时才启用兼容策略。用前端脚本判断是否支持window.PerformanceResourceTiming中的nextHopProtocol属性或者用服务端在 TLS 完成时返回一个标记头让前端知道当前连接协议。如果检测到不是h2就加载一套合并好的兼容版本脚本。逻辑不复杂但能显著避免“新浏览器享受 H2老浏览器灾难”的两头撕裂。3.4 资源加载策略的转变从“合并”到“拆分”这一点值得单独拿出来说。很多团队从 HTTP/1.1 升级到 HTTP/2 后第一个动作是取消资源合并、把所有文件拆碎——这个方向是对的但前提是浏览器真的走了 h2。如果你的用户群中还有相当比例的老浏览器盲目拆分就会变成降级方案的噩梦。我一般的做法是分三层主体框架 JS 和核心 CSS 依然合并成两个文件这两个文件无论如何都会加载按路由拆分的业务代码用动态 import 按需加载享受 HTTP/2 多路复用的好处图片按需懒加载同时针对 HTTP/1.1 场景自动生成雪碧图或 base64 内联。这套策略在 Chrome、Firefox、新版 Safari、Edge 上能享受到 HTTP/2 的拆分优势在 IE11 等老浏览器上也不会因为请求数爆炸而崩掉。跨浏览器支持不是说“按最差的实现”而是“给每个浏览器都安排一个相对合理的方案”。4. 浏览器内核与组件层面的兼容性细节4.1 内核版本和网络栈的关系不是“升级浏览器就好”讨论浏览器支持时很多人只关心“浏览器版本”却忽略了浏览器实际跑在什么内核、什么组件状态之上。尤其在国内复杂的客户端环境里这个问题更加突出。浏览器的 HTTP/2 实现并不只是“照着规范写代码”那么单纯它和底层网络栈耦合很深。以 Blink 内核的 Chrome 为例HTTP/2 会话管理、流调度、连接池都运行在net服务进程里网络栈代码更新往往和内核版本同步。这意味着即便你用的是一个较新版的 EdgeChromium 内核如果内核里的网络栈有问题HTTP/2 行为也会跑偏。实际项目里遇到的一个情况某个银行内网环境用的浏览器是定制版 Chromium 72内核偏老网络栈虽然实现了多路复用但对 HTTP/2 的流控窗口初始值设置异常导致大文件下载时的速度远低于同版本官方浏览器。排查半天才定位到问题在定制浏览器而不是服务器配置。这种问题无法从服务器端彻底解决但你可以通过合理设置 TCP 缓冲区和服务端的流控帧参数尽量让网络行为更中立。跨浏览器支持从来不只是“浏览器版本号”而是内核、网络栈和组件状态的综合表现。4.2 32 位内核组件与老环境下的 HTTP/2 表现再延伸一下。很多老系统上还跑着 32 位浏览器内核组件这个细节很少有人会注意到但它会实实在在地影响 HTTP/2 表现。32 位进程的内存地址空间有限这意味着浏览器网络栈在处理大量并发流时会更快触碰内存瓶颈。HTTP/2 的多路复用把几十个请求塞进一条连接但每个流都要占用独立的缓冲区、流控制窗口计数器等内存结构。在 32 位浏览器里如果同一页面并发资源特别多很容易出现流控窗口枯竭或连接异常关闭表现就是“部分资源一直转圈刷新一下又好了”。还有一个常见问题32 位浏览器组件和 64 位浏览器组件共存在同一台机器上。某些国产浏览器采用双内核架构一个 32 位组件负责兼容老网站一个 64 位组件负责现代站点。如果你访问的站点走了 32 位内核哪怕系统里有 64 位组件已经支持了 HTTP/2这次会话依然是 HTTP/1.1 或准 h2 状态。排查这类问题在浏览器里看内核进程架构非常关键。4.3 覆盖安装与组件升级时最容易犯的错测试过程中我发现一个特别容易被忽略的坑就是浏览器或组件的覆盖安装。很多管理工具会把新版浏览器组件直接覆盖到旧路径如果路径没变旧配置文件、缓存数据库、扩展插件会被一并保留。举个例子用户原本装了 64 位版本的浏览器路径是C:\Program Files\xxx后来 IT 部门用 32 位安装包覆盖安装结果新组件被装到C:\Program Files (x86)\xxx旧目录里的配置文件却还留在原处。这样一个浏览器实例里就可能同时存在两个版本的网络栈代码HTTP/2 的 ALPN 协商和流控制行为会出现随机波动非常难排查。“覆盖安装暂不支持更改路径”这类提示一旦出现千万别忽略。稳妥的做法是升级组件时先完全卸载旧版本、清理配置和缓存目录再全新安装到统一路径。尤其是在企业内网环境里管理几百台终端的浏览器版本最怕的就是新旧组件因为路径混乱而并存。4.4 协议层和媒体编码层是两层HEVC 在浏览器里的“伪支持”教训讨论浏览器支持时经常有人把协议支持和媒体编码支持混为一谈。拿热词里提到的 h.265(HEVC) 在 Edge 里的支持来说很多人以为“浏览器支持 HTTP/2那 HEVC 视频就应该能顺利播放”——这是完全错误的。HTTP/2 解决的是资源怎么传输的问题而 HEVC 能不能播放取决于浏览器解码器是否支持 HEVC 编码格式这是两套完全独立的支持体系。Edge 浏览器Chromium 内核对 HEVC 的硬件解码支持是依赖操作系统媒体框架的和它走 HTTP/1.1 还是 HTTP/2 毫无关系。我在公司做过一个视频网站优化把所有媒体资源切换到 HTTP/2 之后开始排查为什么用户反馈视频加载更流畅了但在 Edge 上部分 HEVC 视频依然黑屏。最后发现根本不是网络传输的问题而是 Edge 只在特定硬件和系统版本下能硬解 HEVC软件解码又没内置。排查问题前先想清楚问题出在传输层还是消费层这两个层面各自有各自的兼容性测试矩阵别混在一起排查否则会把时间浪费在完全错误的排查方向。5. 实测记录在一个存量项目中完整启用 HTTP/25.1 开始前需要检查的三件事说了这么多理论实际操作一把更直观。当时我改造的是一个典型的存量项目后端 Nginx 前端 Vite 构建的 SPA域名走 HTTPS但没有开启 HTTP/2。改造前我做了三个检查都是老项目容易忽略的第一件确认证书链完整。HTTP/2 对证书要求更苛刻证书链断链会导致某些浏览器 ALPN 协商失败。用openssl s_client -connect domain:443 -servername domain -alpn h2命令检查必须在输出里看到 ALPN 协议列表包含 h2。第二件确认当前是否已有资源在走 HTTP/1.1 的旧优化。老项目里往往有combo合并接口把多个 JS 合并返回、域名分片等针对 HTTP/1.1 的优化。这些在 HTTP/2 环境下不仅多余有时还拖慢速度。我会先梳理一把资源加载关系图列出哪些是真正的关键资源哪些可以安全拆分。第三件摸清用户浏览器分布。自己公司的后台、内部员工工具和对外网站的浏览器分布完全不同。通过访问日志里的 User-Agent 统计 HTTP/2 支持率能直接指导你调整降级策略的复杂程度。我们的项目大概 4% 的用户还跑在老旧浏览器上所以做了简单的降级分支而没有投入资源做全链路兼容。5.2 Nginx 配置从 HTTP/1.1 到 h2 的关键改动Nginx 场景下改动其实很小。我的配置关键部分如下server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name example.com; ssl_certificate /etc/nginx/ssl/example.com.crt; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:...; ssl_prefer_server_ciphers on; # 静态资源长时间缓存 location /static/ { expires 30d; add_header Cache-Control public, immutable; } }几个细节解释一下listen 443 ssl http2;是 Nginx 1.25 之前的老写法新版 Nginx 推荐listen 443 ssl; http2 on;。无论哪种写法本质上都是让 Nginx 在 TLS 握手时用 ALPN 告知浏览器支持 h2。TLS 版本至少 1.2。TLS 1.0/1.1 下主流浏览器基本不会协商 h2。如果你还开着老 TLS先关掉。加密套件的选择会直接影响协商成功率。有些老设备只支持AES-CBC套件但 Chrome 和 Firefox 对 h2 的套件策略很敏感建议套件列表里保留几个现代 AEAD 套件同时用ssl_prefer_server_ciphers on保证服务端优先选择安全的那个。改完后用nginx -t校验配置再systemctl reload nginx或nginx -s reload平滑重载。5.3 踩了个坑反向代理和 CDN 回源仍在用 HTTP/1.1这次改造最值得记录的坑不是前端而是链路中间层。我们的架构是 用户 → CDN → Nginx → 后端服务。改完源站 Nginx 后我用浏览器测试始终显示h2一切正常。但后来用真实流量分析工具检查 CDN 节点返回时发现CDN 到源站的回源请求依然走的是 HTTP/1.1。这有什么问题问题就在于如果你在源站对请求头做某些依赖 h2 的处理或者后端服务对请求协议有判断逻辑回源走 HTTP/1.1 可能引发功能缺陷。更重要的是CDN 回源如果还走一遍 HTTP/1.1 的队头阻塞即便用户到 CDN 这一段是 h2整体加速效果也会打折尤其是动态内容需要源站实时返回的场景。排查方法在源站 Nginx 的 access log 里查看$http2变量。如果回源请求显示不是h2说明 CDN 节点 HTTP/2 回源配置没开。这一步容易卡住很多人因为浏览器访问正常但不代表整条链路都享受了 HTTP/2。还有一个容易忽略的点CDN 上如果开启了“回源跟随”或“协议跟随”要确保回源协议也支持 h2。有些 CDN 的默认回源协议是 HTTP/1.1你需要手动改配置为 HTTP/2 回源或者至少确认后端不需要依赖 h2 特性。5.4 验证链路从 Network 面板到 curl 再到日志改造完成后的验证不能只看一眼就完事。我的验证链路是这样第一层浏览器 DevTools Network 面板确认协议列全是h2。这一步可以快速发现问题但对隐藏资源的判断不够全面。第二层覆盖主要浏览器都测一遍。因为项目有 4% 老浏览器用户我特意用 IE11 兼容模式和一台老 Safari 跑了一遍确认降级逻辑生效页面功能正常。这一步很多团队根本不做直到线上有人反馈空白页才追悔莫及。第三层看服务端日志。Nginx access log 里记录$server_protocol字段批量统计 h2/HTTP/1.1 请求占比。这一步最客观它能反映真实用户的协议分布情况还能帮你发现某个地区或某个运营商网络里是否有异常的协议回退现象。第四层用curl --http2 -sI https://example.com确认服务端直接连接下的 h2 支持。如果源站直连不是 h2那 CDN 的 h2 回源配置再怎么看也没用。我的结论是验证一定要从用户视角、源站视角、CDN 链路视角三层分别做任何一层没覆盖就可能漏掉隐藏问题。6. 启用 HTTP/2 之后经常被忽视的浏览器侧陷阱6.1 TCP 与连接重用的调优HTTP/2 只使用一条 TCP 连接这本是优势但也带来一个反直觉的问题TCP 层的拥塞控制对单连接的调优变得更加关键。HTTP/1.1 时代浏览器开 6 条连接即使某条连接暂时丢包其他连接还能继续工作HTTP/2 把所有鸡蛋放进一个篮子一旦 TCP 出现丢包整条连接上的流都会受影响。我实测过同一个页面在差网络环境下模拟 5% 丢包率的表现HTTP/1.1 下页面加载慢但稳定HTTP/2 下反而出现了部分资源长时间挂起的情况。根本原因就是单连接丢包后的重传等待拖累了所有流的进度。服务端可以对 TCP 参数做一些调整比如增大初始拥塞窗口、开启 BBR 拥塞控制算法能显著改善丢包环境下的表现。但浏览器端的调度行为你控制不了能做的是把最重要的资源放到 HTML 文档里内联或者优先加载减少对多路复用链路在弱网环境下的依赖。6.2 头部限制与流量控制HTTP/2 规范允许每个头部字段最大 4KB、整个头部区块不超过 8KB 左右有配套限制。浏览器对超出限制的头部会直接报错或切断连接。在我们项目里就出现过一次后端在响应头里塞了一个特别长的调试信息字段结果浏览器直接加载失败App 里还以为是前端 bug。排查这个问题的方式是在服务端日志里找http2相关的报错或者用 Chrome 的chrome://net-internals查看 session 错误。解决方法是把长头部字段移到请求体或者自定义响应体里别在响应头里玩花活。流量控制Flow Control也是容易被忽略的点。HTTP/2 的每个流都有独立的可调流量窗口浏览器会通告自己的接收窗口大小。如果服务端一次性发太多数据而没有关注浏览器窗口更新有些浏览器会表现得极其保守导致后续数据发送延迟。优化办法是确保服务端不会对单个响应发太多未确认数据特别是大文件响应要配合合理的流控帧设置。6.3 服务器推送的“隐形代价”CSS 和图片推送的案例分析前面提到了推送的副作用这里用一个具体案例说明。当时我尝试把首屏 CSS 和首屏图推送给用户结果 Chrome 下首屏时间缩短了约 80ms但 Firefox 下反而出现了约 120ms 的延迟。原因就是 Firefox 对推送的资源缓存态度不同它把推送来的 CSS 放进内存缓存页面解析时可能已经过期或需要重新验证整体没占到便宜。后来我放弃推送改成“关键 CSS 内联 非关键 CSS 异步加载”效果反而稳定Chrome、Firefox、Safari 下都有一致的首屏提升。推送这个功能本身没问题但它在不同浏览器里的实现差异太大非标准场景下反而像是给自己挖坑。如果你确实要使用推送建议遵守三条只推用户 100% 会用到的高置信度资源推送资源要设置短缓存或隐私缓存避免重复传输实时监控“推送后又被请求”的比例如果超过 10%说明推送策略有问题。6.4 兼容性陷阱清单遇到问题先照着查最后整理一个我多次踩坑后沉淀的检查清单遇到 HTTP/2 浏览器兼容性问题时先照着查一轮往往能省下大量抓包时间现象可能原因检查方法全部资源都走 HTTP/1.1TLS 版本太低或加密套件不受支持ALPN 未启用openssl s_client 检查 ALPN查看 TLS 版本部分资源走 HTTP/1.1CDN 节点或子资源服务器未启用 h2跨域请求走了独立连接Network 面板按协议排序检查子域配置首屏图片加载极慢浏览器对低优先级流调度保守Safari 常见调整图片加载优先级关键图内联或 preload资源反复加载服务器推送资源缓存策略设置错误检查推送资源 cache-control考虑禁用推送大文件下载不稳定流控窗口或 TCP 拥塞控制问题调整 Nginx 缓冲区开启 BBR页面偶发“部分资源空白”单连接 TCP 丢包或 32 位内核内存瓶颈抓包确认重传考虑降级策略老浏览器白屏降级逻辑没生效合并资源策略未启用检查协议检测脚本启用 fallback 资源包控制台出现 Net::ERR_HTTP2_PROTOCOL_ERROR服务端头部太大或非法帧CDN 回源配置冲突查看服务端日志精简响应头我自己在项目里最深的体会是HTTP/2 协议本身很成熟真正的复杂度全在浏览器兼容性这一层。别把 Can I Use 上的绿色看成护身符用户端的浏览器内核、组件状态、网络环境千差万别只有先承认这些差异才可能做出真正稳定的跨浏览器支持方案。每次排查到深夜的时候我都是靠这份清单一步步缩小范围的。如果你也在折腾这玩意希望这篇分享能让你少走几条弯路。