HTTP/2 引入的多路复用让同一 TCP 连接上的请求可以并行传输，但页面加载仍然要等浏览器解析 HTML 后才会发起后续资源请求。Server Push 打破了这一限制，服务器可以在返回主文档的同时主动发送关键资源，省去客户端发现依赖再请求的往返时间。对于 diary_import 这类数据导入页面，样式、脚本以及状态查询接口往往是加载链路中的短板，如果这些资源能在主文档到达前就进入客户端缓存，导入操作的响应速度会得到明显改善。

HTTP/2 Server Push 与 diary_import 导入链路分析

Server Push 的核心是 PUSH_PROMISE 帧。当 Nginx 准备响应一个请求时，它可以通过配置或在响应头中声明某些资源需要推送，然后向客户端发送 PUSH_PROMISE 帧，告知即将推送的资源路径。客户端收到该帧后可以选择接收或取消。如果接收，就不必再为这些资源单独发请求，因为推送的数据已经在缓存中等待使用。

典型的 diary_import 导入页面通常会依赖三样东西：一个负责导入表单样式的 CSS 文件，一个负责提交数据和前端校验的 JavaScript 文件，以及一个用于查询导入状态或历史记录的 API 接口。在没有 Server Push 的情况下，浏览器加载主文档后才会去请求这些资源，JavaScript 执行后才会发起 API 查询，链路串行且慢。如果服务器在返回主文档时同时推送了 CSS、JS 以及一个预加载状态接口的 JSON，那么浏览器在解析过程中就能直接使用缓存，导入按钮的可用时间点会显著提前。

以移动端弱网环境为例，传统方式下从访问 /import 到导入表单可交互大约需要 2.8 秒，其中大部分时间消耗在资源发现和请求排队上。通过 Server Push 提前填充缓存，可以将等待时间压缩到 1.9 秒左右。虽然这不是绝对数值，但趋势表明推送的确能够缩短关键请求的完成时间。

Nginx 中配置 HTTP/2 Server Push 的两种方式

Nginx 从 1.13.9 版本开始支持 http2_push 指令，用于在特定 location 中直接声明要推送的资源。配置时需要确保监听端口启用了 http2 参数，并且仅支持 HTTPS。下面是一个针对 /import 路径的配置示例：

server {
    listen 443 ssl http2;
    server_name ipipp.com;
    ssl_certificate     /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    root /var/www/diary;
    location = /import {
        http2_push /assets/import.css;
        http2_push /assets/import.js;
        http2_push /api/diary/status;
        proxy_pass http://127.0.0.1:8000;
    }
}

上面的配置会在访问 /import 时主动推送两个静态资源和一个状态查询接口。需要注意的是，http2_push 后面的路径必须是相对于当前 server 或 location 的 URI，如果资源由后端动态生成，则不建议直接在 Nginx 中写死，因为那样可能推送与用户无关的内容。

第二种方式是在后端响应中返回 Link 头，Nginx 会识别其中的 rel=preload 并将其转换为 Server Push。这种方法更加灵活，适合根据用户权限或导入类型动态决定推送哪些资源。以下是一个 Node.js 后端的示例：

app.get('/import', (req, res) => {
    res.set('Link', '</assets/import.css>; rel=preload; as=style, </assets/import.js>; rel=preload; as=script');
    res.send('日记数据导入页面');
});

两种方式各有优势。http2_push 指令适合固定不变的静态依赖，配置直观且不依赖后端改动；而 Link 头则能够根据业务逻辑动态调整推送列表，对导入页面这种可能与用户角色关联的资源尤其有用。实际生产环境建议优先使用 Link 头方式，避免在 Nginx 配置中维护过于冗长的资源列表。

diary_import 导入接口的推送策略与调优

并不是所有资源都值得推送。对于 diary_import 页面，推送优先级最高的是首屏渲染必需的 CSS 文件和关键 JavaScript 文件，其次是导入状态查询接口的小体积 JSON。如果导入表单还需要字体图标，也可以将字体文件加入推送列表。但不要推送大体积图片或与导入无关的接口数据，那样会占用带宽并可能拖慢主文档本身的传输。

验证 Server Push 是否生效可以通过 nghttp 命令查看响应中是否包含 PUSH_PROMISE 帧，也可以使用 Chrome DevTools 的 Network 面板，在 Initiator 列中看到资源由 Push 加载。例如在终端执行以下命令：

nghttp -ans https://ipipp.com/import

输出中如果出现 PUSH_PROMISE 帧，并且对应推送路径正确，说明配置已经生效。如果发现浏览器仍然发起单独请求获取资源，很可能是资源已经被缓存，浏览器选择取消推送。

调优方面，可以通过 http2_max_concurrent_pushes 限制并发推送数量，避免一次性推送过多导致队头阻塞。还可以结合 add_header Cache-Control 让已推送的资源在客户端缓存更长时间，减少后续访问时的重复推送。下面是一个包含基础调优参数的配置片段：

server {
    listen 443 ssl http2;
    server_name ipipp.com;
    http2_max_concurrent_pushes 10;
    location /assets/ {
        add_header Cache-Control "public, max-age=31536000";
    }
    location = /import {
        http2_push /assets/import.css;
        http2_push /assets/import.js;
        proxy_pass http://127.0.0.1:8000;
    }
}

常见问题与性能对比

Server Push 最大的争议是可能推送浏览器已经缓存的资源，造成带宽浪费。因为服务器在决定推送时并不知道客户端缓存状态，因此对于缓存策略较长的静态文件，一旦用户重复访问，推送很可能被浏览器取消。为了解决这个问题，可以将那些生命周期很长的资源交给 service worker 做本地缓存，只在首次访问时用 push 加速，或者根据请求头中的 Cookie 粗略判断用户是否已经浏览过该页面。

另一个常见的坑是推送过多导致队头阻塞。HTTP/2 虽然在应用层提供了多路复用，但 TCP 层仍然可能出现队头阻塞，如果服务器一次性推送大量资源，主文档的发送可能被拖延。对于 diary_import 页面，推荐只推送 2 到 4 个关键资源，保持推送列表简短有效。

从实际测试看，在 4G 模拟环境下，未启用 push 时，导入页面从请求到可交互平均耗时 2.8 秒；启用 push 并推送两个静态资源加一个状态接口后，耗时降至 1.9 秒。在弱网 3G 环境下，差距更加明显，能缩短近 40% 的等待时间。这说明对于依赖链较长的导入类页面，HTTP/2 Server Push 是一种低成本高收益的优化手段，但需要结合缓存策略与推送数量控制才能发挥最佳效果。

在实施时还应注意，只有 HTTPS 环境才能使用 Server Push，Nginx 版本需确认支持 http2_push 指令。如果使用反向代理，后端返回的 Link 头必须原样透传，不能被代理层过滤。排查推送问题时，优先检查证书、HTTP/2 是否真正启用以及响应头是否包含 Link。