push cache 是 http/2 定义的临时缓存层，位于 memory cache 和 disk cache 之间，仅存活于当前 https 连接期间，路径完全匹配时可被后续请求直接命中，优先级高于 disk cache 但不受 cache-control 控制。
HTTP/2 Server Push 并不“打破”传统缓存链条，而是在请求发起前就将资源注入浏览器的缓存层级中，形成一条独立于常规 HTTP 缓存流程的临时缓存路径——即 Push Cache。
它不是替代 Cache-Control 或 ETag，而是新增一层短生命周期、高优先级、与连接强绑定的缓存机制。关键在于：推送资源不经过常规请求流程，却能被后续 fetch 或资源加载直接命中。
Push Cache 是什么？它在哪一级？
Push Cache 是 HTTP/2 协议定义的、浏览器实现的临时缓存层，位于 Memory Cache 和 Disk Cache 之间，但更特殊：
- 生命周期极短：仅存活于当前 TCP 连接期间；连接关闭即清空
- 范围受限：只对同源、同协议（HTTPS）、同连接的后续请求有效
- 不受 Cache-Control 控制：即使响应头中
Cache-Control: no-store，仍可能进入 Push Cache - 优先级高于 Disk Cache：浏览器会优先查 Push Cache，再查 Disk/Memory
举例：服务器在响应
/index.html时推送/style.css，浏览器收到后立刻存入 Push Cache。当 HTML 解析到<link href="/style.css">时，不发新请求，直接从 Push Cache 取出使用。
如何让推送资源真正“可用”而非被丢弃？
推送本身不保证资源被使用。要让 Push Cache 发挥作用，需满足三个隐性条件：
-
路径必须完全匹配：推送的
:path帧字段（如/style.css）必须与后续 HTML 或 JS 中实际请求的 URL 字符串完全一致（含大小写、斜杠、查询参数） - 不能跨域或跨协议：推送只能发生在同一 origin 的 HTTPS 连接中；HTTP/1.1 或非 TLS 连接不支持
-
浏览器未主动拒绝：现代 Chrome/Firefox 默认接受推送，但若页面已通过
fetch()显式请求过该 URL，部分浏览器会忽略推送（避免重复）
与传统缓存策略如何协同？
Server Push 和传统缓存不是互斥关系，而是分阶段协作：
- 首次访问（无任何缓存）：Server Push 抢在 HTML 解析完成前把 CSS/JS 推送进来 → 直接填入 Push Cache → 渲染不阻塞
-
二次访问（已有 Disk Cache）：浏览器优先走 Disk Cache（因 Push Cache 已失效），此时
Cache-Control生效，无需推送 -
接口类资源（如
/api/user）：适合持续推送（因无强缓存），配合http2_push_preload+Link: rel=preload; as=fetch，让浏览器既接收推送又触发预加载逻辑
注意：静态资源（CSS/JS/图片）是否推送，需权衡缓存复用率。若
Cache-Control: max-age=31536000，推送大概率浪费带宽；若资源动态生成（如带用户 ID 的app.js?uid=123），则每次都是新 URL，Push Cache 正好补位。
实际配置中的关键细节
不同服务器实现差异大，但核心逻辑一致：
- Apache：用
H2PushResource /style.css指令，在响应 HTML 时自动触发推送 - Nginx（≥1.13.9）：
http2_push /style.css强制推送；或http2_push_preload on+add_header Link "/data>; rel=preload; as=fetch; crossorigin"动态触发 - Node.js（如 http2 模块）：需手动调用
stream.pushStream({ ':path': '/style.css' })，再 writeHead/write 推送响应，不能靠前端加<link rel="preload">伪造
⚠️ 重点：
<link rel="preload">是客户端提示，Link: rel=preload响应头是服务端提示，二者都不等于 Server Push。只有服务器主动发PUSH_PROMISE帧，才算真正启用。
本质上，Server Push 不绕过缓存链，而是在链最前端插入一个瞬时、专用、协议级的缓存入口。它不取代 Cache-Control，但能填补首屏加载中“请求发出前”的空白期。用得好，省下一个 RTT；用得滥，反而增加冗余传输。
