首屏资源提前加载的中间响应码，为什么多数情况只在多路复用协议下发

首屏资源提前加载用的中间响应码，之所以多数情况只在多路复用协议上发送，是兼容与安全两方面的原因：旧协议下客户端处理多个响应的边界不稳妥，多数浏览器也因此把支持限制在协议 2 或更高版本。这个中间响应本身解决的是等待时间——服务器还在准备页面时，先把「待会儿会用到哪些来源」告诉客户端。

中间响应码解决的是哪一段等待

一次首屏加载里，耗时的构成不只是页面本身：建立连接、协商加密、取回样式与脚本，每一步都要等前一步。页面在服务器端组织的时候，客户端这段时间完全空转。这类中间响应的作用是把这个空档利用起来：服务器还在准备最终响应时，先返回一条提示，说明待会儿会用到的资源来源，客户端可以提前预连接，也可以开始预加载。

提示里通常放哪一类头

按文档说明，这种提示主要配合链接头使用，它的语义就是标出要加载的资源；同时可以带一条内容安全策略头，在处理提示阶段就生效。也就是说它并不是「提前把页面发出去」，而是把两类不依赖页面内容就能决定的信息提前告知：来源地址与策略。真正的内容仍然由后面的最终响应给出。

为什么限制在多路复用协议之上

文档给出的理由是兼容与安全，并明确建议只在协议 2 或更高版本上发送，除非已知客户端能正确处理中间响应；多数浏览器对这个的支持也限制在协议 2 以上。差别在协议如何处理一个请求对应多个响应。多路复用协议天然把同一请求上的多个响应分开成独立的帧，中间响应不会污染最终响应的状态。旧协议下客户端要把同一条连接上的先后两段响应拆开，历史实现里这类拆分最容易出问题，甚至会把提示当成不完整页面来处理。风险落在兼容性最差的那批客户端上，收益却只体现在首屏一段连接建立的耗时。

站点层能不能直接配上

要确认三件事：程序会不会发出中间响应、前置层会不会把它丢掉、协议是不是多路复用版本。程序侧要能在页面组织完成之前返回提示，通常依赖框架或服务器模块支持。前置层是最常见的断点：缓存、反向代理与压缩环节可能只透传最终响应，中间响应在转发时被忽略。AnQiCMS 的部署一般是前置服务器反代到默认监听的 8001 端口，要验证的是这条链路上每一跳的协议版本与转发行为，而不是只看站点自身配置。

哪些情况不该指望它

三类情况收益接近于零。资源全部同源、没有外部域名时，预连接省不出什么时间；最终响应本身在很短时间内就能返回时，提示的提前量还不足以走完一次连接协商；链路上有组件会吞掉中间响应时，配了也没有效果。反过来，第三方来源多、协商耗时高的页面，才是这项能力真正适用的场景。页面加载速度对内容站的重要性有官方口径，AnQiCMS 的说法是相比传统 PHP 程序有显著提升、单机可承载约 500 万 PV，但这类中间响应只解决首屏里连接建立的一小段，不能拿它替代资源体积与缓存策略。

常见问题

问：客户端不支持这个响应码会怎样？ 答：按协议它会被当作中间响应忽略，最终响应仍会正常返回；风险在于旧协议下的处理差异，这也是建议限制在协议 2 以上的原因。

问：开了之后首屏时间能省多少？ 答：取决于原本要等待的连接协商数量，省的是建连与协商的时间，不是页面生成时间。

问：本地测试看到提示、线上看不到，先查哪里？ 答：先查前置层的转发行为与协议版本，再确认程序在哪一层能发出提示。