题干与适用场景
你负责一个首屏 HTML 需要较长时间生成的电商首页。候选方案是在最终响应前发送 103 Early Hints，提前提示关键 CSS、字体或脚本。请说明它何时有效、如何避免重复下载，以及如何验证 LCP 是否改善。假设请求是顶层导航，连接使用 HTTP/2 或 HTTP/3，最终响应仍会发送正确的 Link 头。
面试官考察点
- 能否把 103 说成“提示”而非最终资源清单：浏览器可提前连接或预加载，但最终响应仍是权威来源。
- 能否识别收益来自服务器生成 HTML 的等待时间；若服务器立即返回 200，主响应中的
preload或preconnect更简单。 - 能否处理资源稳定性、缓存、跨源重定向、浏览器支持和协议版本等边界。
- 能否用 LCP、缓存命中、重复请求和错误率验证，而不是只背状态码。
回答前需要澄清的问题
- 首个字节前的服务器时间多长？ 若几乎为零，103 没有可重叠的等待窗口，应优先优化后端或主响应资源提示。
- 提示的资源是否稳定且必需？ 若依赖用户、实验或权限结果，误提示会浪费带宽；应只提示跨页面稳定的关键资源。
- 请求是否为顶层导航、连接是否为 HTTP/2+？ 浏览器对 103 的处理主要针对导航，并建议在 HTTP/2 或更高版本使用。
- 资源是否可缓存？ 不可缓存的预加载可能在 HTML 到达后再次下载，收益会变成额外开销。
30 秒回答框架
“我先确认页面有足够的服务器思考时间，以及请求是支持 103 的顶层导航。然后只提示大概率必需、稳定、可缓存的 CSS、字体或连接来源，并在最终响应重复正确的 Link 头。若资源依赖实验或用户权限，我不会提前提示。上线前后用真实导航比较 TTFB 到资源请求的重叠、LCP、重复下载和带宽；遇到跨源重定向或不支持的客户端则回退到普通响应。”
分步骤深入解答
1. 先计算可重叠的时间窗口
103 让浏览器在服务器准备最终 HTML 时开始连接或下载资源。可获得的上限接近“服务器准备时间减去浏览器收到最终响应后才开始请求资源的时间”。服务器很快返回 200 时，这个窗口接近零，Chrome 官方建议使用主响应中的常规 Link 或 HTML link。
2. 选择稳定资源，而不是复制全部 HTML 提示
Early Hints 没有最终 HTML，也不知道用户最终看到的变体。适合候选包括稳定的主 CSS、共用脚本、字体和关键 CDN 连接。个性化图片、实验分支脚本和权限资源应留在最终响应后。可以把资源拆成稳定部分和动态部分：前者提前提示，后者由 HTML 决定。
3. 把缓存和协议当作正确性条件
预加载资源必须能被最终页面复用；若资源不可缓存，浏览器可能先下载一次，随后 HTML 再触发一次。跨源资源还要保持正确的 crossorigin 语义。MDN 建议优先在 HTTP/2 或更高版本发送 103，老客户端或中间设备可能无法正确处理 1xx 响应。
4. 保留最终响应的权威声明
最终响应应继续发送 Link 头，作为不支持 103 客户端的回退，也补充在生成 HTML 期间才知道的动态资源。若最终结果发生跨源重定向，浏览器可能丢弃早期建立的连接和资源；因此不能把 103 当作不可撤销的下载指令。
5. 用实验验证而不是假设收益
在支持与不支持 Early Hints 的真实导航上分组，记录服务器思考时间、资源请求开始时间、LCP、重复请求字节数和错误率。Chrome DevTools 可观察 Early Hints initiator 与缓存命中，但测试时不能关闭缓存。若 LCP 没有改善，检查提示资源是否已在缓存中、是否过晚发送、是否被重定向丢弃，或服务器等待本身才是瓶颈。
6. 与 HTTP/2 Push 的区别
103 只提供线索，由浏览器决定是否连接或获取；HTTP/2 Push 直接推送，容易重复发送浏览器已经缓存的资源。面试中应强调 103 的控制权留在客户端，代价是仍需一个网络往返并受浏览器支持限制。
高质量示范回答
我会先看首字节前的服务器时间。如果首页 SSR 需要 300 毫秒，而主 CSS 和字体在每次导航都稳定存在，103 可以让浏览器把连接和下载放到这 300 毫秒里。我的 103 只放稳定、可缓存的资源，并确保跨源字体带上正确的 crossorigin；个性化图片和实验脚本不提前发。最终响应仍发送 Link，这样不支持 103 的客户端也能正常加载。
我不会把它当成状态码加上就一定提速。我要用真实导航做对照实验，比较 LCP、资源请求起点、重复下载字节和跨源重定向比例。若服务器很快返回 200、资源已在缓存中、或提示资源经常被最终页面否决，普通主响应提示甚至不做预加载更合适。这个回答同时覆盖收益窗口、错误成本和回退路径。
常见错误
- 错误表现 → 认为 103 等同于 200。 失败原因：103 是信息提示，最终响应才决定资源和状态。修正方法：说明提示可被忽略，并保留最终
Link。 - 错误表现 → 把所有 HTML 中的
preload原样复制到 103。 失败原因：早期阶段没有用户变体信息，动态资源会产生浪费。修正方法：只选择稳定且高概率必需的资源。 - 错误表现 → 只看 LCP，不看重复下载。 失败原因：预加载不可缓存或跨源属性错误时，表面上可能更早发起请求却增加总字节。修正方法：同时记录缓存复用、重复请求、带宽和错误率。
- 错误表现 → 默认对所有 HTTP/1.1 请求发送。 失败原因：客户端和中间设备对 1xx 支持不一致，且 Early Hints 主要针对导航。修正方法：按协议、请求类型和客户端能力启用，并准备普通响应回退。
追问及应对
如果最终响应经常 302 到另一个源，103 还该发吗？
谨慎发。MDN 和 Chrome 资料都指出，跨源重定向后浏览器可能丢弃早期资源和连接。先把 103 限定在稳定的最终入口，或只提示不会因重定向失效的同源资源，并用重定向比例作为门槛。
如果 CSS 在不同实验组不同，如何提示？
只提示所有实验组共享的基础 CSS，实验专属部分留到最终 HTML。若没有稳定交集，就不要预加载；错误预取的带宽成本可能超过节省的等待时间。
如何证明收益来自 103 而非缓存变热？
使用相同缓存状态的随机分组，并分别记录冷缓存和热缓存。比较资源请求与服务器思考时间的重叠，而不只比较单次 LCP；同时检查 Early Hints initiator、缓存命中和重复下载。
浏览器不支持某个 Early Hints 指令怎么办？
保持最终响应的 Link 和 HTML 声明作为回退。先发送兼容性更广的 preconnect，对 preload 则按目标浏览器支持矩阵逐步启用，并监控错误率。