Fetch keepalive 适合发送哪些小请求

页面关闭、刷新或跳转时，普通 fetch() 可能还没发完就被卸载流程中断。keepalive 适合解决的正是这一小段生命周期问题：把少量、可丢失、无需等待结果的数据尽力送到服务端，例如阅读时长、最后一次页面状态或轻量埋点。它不是大文件上传器，也不是可靠消息队列。实际使用时，我会先看载荷大小和业务后果，再决定是否开启。

官方地址：https://developer.mozilla.org/en-US/docs/Web/API/RequestInit

先用体积和生命周期判断适用范围

我在性能排查中通常先把请求分成三类。第一类是“页面走了也不影响主流程”的小数据，例如一次阅读结束事件；第二类是希望尽量发送、但丢失后可以通过后续批量同步补回的数据；第三类是订单提交、权限变更、草稿保存等必须得到确认的关键写入。只有前两类有理由考虑 keepalive。

它的关键价值不是让网络变快，而是页面发起方卸载后，浏览器仍尽力继续请求。MDN 同时说明这类请求的 body 有 64 KiB 限制，因此图片、长文本、离线队列和大批量埋点都应在进入 fetch 前拦截。若业务需要可靠投递，应使用服务端幂等、后续补偿或专门的队列。

用小型 JSON 发送离开页面状态

下面的封装把“是否过大”放在请求之前判断，并给事件加一个幂等标识。示例使用 pagehide，因为它表达页面即将离开当前文档；事件处理器不等待 Promise，也不把请求结果当作页面离开成功的证明。

function reportPageExit(viewId) {
  // 只携带必要字段，避免离开页面时发送大对象。
  const payload = JSON.stringify({
    viewId,
    event: "page_exit",
    occurredAt: Date.now(),
    idempotencyKey: crypto.randomUUID()
  });

  // 64 KiB 是硬边界，实际项目还要给请求头和编码变化留余量。
  if (new TextEncoder().encode(payload).byteLength > 60 * 1024) {
    console.warn("跳过过大的离开事件");
    return;
  }

  fetch("/api/telemetry/page-exit", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: payload,
    keepalive: true,
    credentials: "same-origin"
  }).catch(() => {
    // 页面可能已卸载，失败只做本地记录，不阻塞离开动作。
    console.info("离开事件未确认送达");
  });
}

window.addEventListener("pagehide", () => {
  // 这里传递页面自己的短标识，不读取或上传整份状态树。
  reportPageExit("article-42");
});

这里用 60 KiB 而不是把预算顶到 64 KiB，是为了给 JSON 编码、请求头和未来字段留一点余量。服务端应按 idempotencyKey 去重，并快速返回；前端即使收不到响应，也不能把这类事件当成已确认写入。

把离开页面的小请求做成可控链路

真正上线时，事件监听只是入口。体积门槛负责挡住明显不适合的数据，接口负责校验时间戳和幂等键，日志则记录“尝试发送”而不是虚构“发送成功”。对于跨域接口，还要提前处理 CORS、凭据和预检请求；如果一次离开动作会触发复杂预检，收益可能被网络协商抵消。

常见问题

keepalive 和 sendBeacon 应该怎么选？

两者都适合页面卸载附近的尽力发送。需要自定义方法、请求属性或读取 Fetch Promise 时选 keepalive；只想发送一小段分析数据且不关心响应时，sendBeacon() 往往更直接。

keepalive 请求失败可以自动重试吗？

不要在卸载回调里做多次重试。把事件写入受控的本地小队列，下一次页面打开后补发，并让服务端用幂等键接受重复尝试。

HTTP 返回 500 会进入 catch 吗？

不会仅因为 500 就进入 catch。Fetch Promise 通常仍会 resolve，需要在页面尚未卸载的普通请求里检查 response.ok 或 response.status；离开页面请求则不要把未读到响应理解为成功。

判断标准可以压缩成一句话：数据小、丢了可接受、无需等待响应，并且服务端能幂等处理时，Fetch keepalive 才是合适的工具；只要其中一项不成立，就应把提交提前到页面仍然可交互的阶段。