js刷新当前页面时，如何处理缓存与页面状态？

刷新页面看起来只是重新载入一次，但实际涉及几件不同的事：浏览器是否复用 HTTP 缓存、Service Worker 是否拦截请求、页面中的 JavaScript 状态是否还在，以及表单或滚动位置能否恢复。把这些问题都叫作“清缓存”，容易采用无效甚至有副作用的做法。

本文说明如何刷新当前页面、如何有针对性地控制资源缓存，以及如何在刷新前后保存和恢复页面状态。示例可直接放进普通网页运行；涉及服务器缓存策略的部分需要在服务端配置，单靠前端 JavaScript 无法替代。

一、先分清“刷新”“缓存”和“页面状态”

浏览器的 HTTP 缓存主要针对 HTML、JavaScript、CSS、图片等网络资源。它依据响应头、请求头和缓存校验结果决定是否复用已有响应。重新加载页面时，浏览器可能直接使用新鲜缓存，也可能向服务器验证缓存内容，或重新下载资源。具体行为受浏览器、用户操作和缓存策略影响。

页面状态则是当前运行中的数据，例如输入框内容、搜索条件、当前选中的标签、未提交的编辑内容，以及滚动位置。普通刷新会销毁当前文档并重新执行页面代码；如果这些状态只存在于 JavaScript 变量或组件内存里，刷新后通常就会丢失。

此外还有几类容易混淆的机制：

• HTTP 缓存：浏览器按 HTTP 缓存规则保存和复用网络响应。
• 内存状态：只存在于当前页面运行过程中的变量、组件状态等，刷新通常会丢失。
• Web Storage：sessionStorage 和 localStorage 可保存少量字符串数据；它们不是 HTTP 缓存。
• 后退/前进缓存（bfcache）：部分浏览器可能把离开页面时的整个页面快照暂存起来，后退或前进时恢复。它与普通 HTTP 缓存不同，也不等同于主动刷新。
• Service Worker：可拦截页面请求并自行返回缓存或网络响应，可能改变你对“刷新是否拿到最新资源”的预期。

因此，先确定目标：只是重新执行页面、希望资源更新、需要保留表单，还是要清除某种缓存。不同目标对应不同处理方式。

二、刷新当前页面：使用 location.reload()

最直接的写法是：

window.location.reload();

它会重新加载当前 URL。刷新通常会发起文档加载，但浏览器仍会按照缓存规则处理页面及其依赖的资源；这不代表一定绕过所有缓存。

不要依赖下面这种写法来强制清缓存：

window.location.reload(true);

历史上，部分浏览器曾支持给 reload() 传入布尔值以尝试跳过缓存。但这个参数不是可靠的跨浏览器方案，在现代浏览器中不应依赖；它也不能清除 Service Worker 缓存、代理缓存或 CDN 缓存。调用 location.reload() 即可表达通常的刷新需求。

如果只是跳转到当前地址，下面的代码也会触发导航：

window.location.href = window.location.href;

但这并不会自动获得比 reload() 更强的缓存控制能力。通常使用语义更明确的 location.reload() 即可。

三、需要更新内容时，正确处理 HTTP 缓存

如果页面刷新后仍看到旧文件，问题可能在服务器返回的缓存策略，而不是刷新代码。静态资源一般应采用“文件名含内容哈希、长时间缓存”的方式；HTML 则通常需要短缓存或重新验证，以便用户能发现最新的资源文件名。

例如，构建后的文件名可以带版本哈希：

<script src="/assets/app.4f21c8.js"></script>

当代码内容变化时，构建工具生成新的文件名。浏览器可以长期缓存旧文件，因为新版 HTML 会引用新文件。这比每次刷新都试图绕过缓存更可靠，也能减少不必要的网络传输。

服务器可使用 Cache-Control 响应头控制缓存行为。常见取值包括：

• max-age=秒数：响应在指定时间内可视为新鲜。
• no-cache：允许存储，但使用前需要重新验证；它不等于“完全不缓存”。
• no-store：要求缓存不要存储该响应，适用于确实不应被缓存的内容，但会牺牲缓存带来的性能收益。
• private：响应可由用户侧的私有缓存保存，不应由共享缓存保存。
• public：响应允许共享缓存保存，使用前应评估其中是否含有用户相关内容。

例如，服务器对 HTML 发送如下响应头，可以要求浏览器每次使用前重新验证：

Cache-Control: no-cache
ETag: "page-v42"

浏览器后续可能携带条件请求头进行验证；如果资源未变化，服务器可以返回 304 Not Modified，浏览器继续使用已有响应内容。是否采用这类策略、验证器如何生成，都应由服务器和部署架构决定。

不要为了“确保更新”就给所有响应设置 no-store。它会使重复访问更难利用缓存，影响性能；如果使用缓存的资源发布方式设计得当，通常没有必要对所有资源禁用缓存。对于含有敏感信息的响应，应结合认证、缓存层级和服务器策略审慎配置，不能只凭一个前端刷新动作保证数据安全。

四、只控制某个网络请求的缓存

对于使用 fetch 获取的数据，可以在请求选项中设置缓存模式：

async function loadLatestData() {
  const response = await fetch("/api/items", {
    cache: "no-cache"
  });

  if (!response.ok) {
    throw new Error(`请求失败：${response.status}`);
  }

  return response.json();
}

loadLatestData()
  .then(data => console.log(data))
  .catch(error => console.error(error));

cache 选项用于表达该请求与浏览器 HTTP 缓存交互的方式，常用值包括 default、no-cache、reload、force-cache 和 only-if-cached。其中，no-cache 通常表示使用缓存前需要验证；reload 表示请求时不优先使用已有缓存，但不应把它理解为清空浏览器所有缓存。服务器、浏览器和 Service Worker 的行为仍需分别考虑。

only-if-cached 通常还要求使用 mode: "same-origin"；跨域请求不能据此任意读取浏览器缓存。不同运行环境对请求模式、缓存和 Service Worker 的处理也可能有差异。不要把这些选项当作服务器缓存头的替代品。

下面的写法将时间戳拼进 URL，形成不同的请求地址：

const url = `/api/items?t=${Date.now()}`;
const response = await fetch(url);

这类“缓存破坏参数”可能让缓存层把它视为新地址，但并非通用的强制刷新开关：服务器、CDN、代理和 Service Worker 可能采用不同的缓存键规则；每次生成新 URL 还可能造成缓存命中率下降。对于静态发布文件，优先使用内容哈希文件名；对于 API，优先设计正确的响应头和数据更新策略。不要把敏感数据放进 URL 参数，因为 URL 可能出现在日志、历史记录或其他可见位置。

五、刷新时保留页面状态：选对存储位置

需要保留的状态大致可以分为三类：

• 只需在当前标签页的刷新或页面跳转后暂存：可考虑 sessionStorage。
• 需要跨浏览器重启保留：可考虑 localStorage，但要设定过期和清理规则。
• 适合分享、书签或前进后退的状态：可放入 URL 查询参数或路径；避免放入机密信息。

两种 Web Storage API 都按来源（origin）隔离，并只能保存字符串。它们有容量限制，实际可用容量因浏览器而异，写入也可能因隐私设置、配额或其他原因失败。它们是客户端存储，不是加密保险箱；同一来源运行的脚本通常可以读取其中内容。不要保存密码、访问令牌或不应暴露给页面脚本的敏感信息。

示例：用 sessionStorage 保存和恢复筛选条件

以下示例可以单独保存为 HTML 文件运行。用户提交筛选条件时先保存，页面加载时恢复；刷新本页会继续使用这个标签页中的条件。

<label>
  关键词：
  <input id="keyword" type="text" autocomplete="off">
</label>

<label>
  状态：
  <select id="status">
    <option value="">全部</option>
    <option value="open">进行中</option>
    <option value="done">已完成</option>
  </select>
</label>

<button id="search" type="button">查询</button>
<button id="clear" type="button">清除条件</button>
<p id="message" aria-live="polite"></p>

<script>
  const STORAGE_KEY = "demo:filters:v1";
  const keywordInput = document.querySelector("#keyword");
  const statusSelect = document.querySelector("#status");
  const message = document.querySelector("#message");

  function saveFilters() {
    const filters = {
      keyword: keywordInput.value,
      status: statusSelect.value
    };

    try {
      sessionStorage.setItem(STORAGE_KEY, JSON.stringify(filters));
      message.textContent = "条件已保存。刷新页面后仍可恢复。";
    } catch (error) {
      message.textContent = "当前浏览器无法保存条件。";
      console.error("保存筛选条件失败：", error);
    }
  }

  function restoreFilters() {
    try {
      const raw = sessionStorage.getItem(STORAGE_KEY);
      if (!raw) return;

      const filters = JSON.parse(raw);

      if (filters && typeof filters === "object") {
        if (typeof filters.keyword === "string") {
          keywordInput.value = filters.keyword;
        }

        const allowedStatuses = ["", "open", "done"];
        if (allowedStatuses.includes(filters.status)) {
          statusSelect.value = filters.status;
        }
      }
    } catch (error) {
      sessionStorage.removeItem(STORAGE_KEY);
      console.error("恢复筛选条件失败：", error);
    }
  }

  document.querySelector("#search").addEventListener("click", () => {
    saveFilters();
    // 在这里使用 keywordInput.value 和 statusSelect.value 发起查询。
  });

  document.querySelector("#clear").addEventListener("click", () => {
    sessionStorage.removeItem(STORAGE_KEY);
    keywordInput.value = "";
    statusSelect.value = "";
    message.textContent = "已清除保存的条件。";
  });

  restoreFilters();
</script>

示例中没有把存储的字符串直接插入 innerHTML，而是赋值给表单控件或 textContent。如果数据来源可能被篡改，恢复时仍应验证类型、长度和允许值；不能因为数据来自 Storage 就认为它可信。存储或解析失败也应有处理，避免浏览器禁用存储时整个页面功能中断。

如果筛选条件本身不敏感，而且用户需要复制链接分享结果，可以将状态写进 URL。这样刷新、复制链接和书签都更直观，但要考虑 URL 长度、历史记录、服务器日志以及参数校验。复杂或敏感的页面状态不适合直接放进 URL。

六、在刷新前保存：不要把 beforeunload 当作可靠存储机制

可以监听输入事件，持续保存草稿，而不是等用户刷新时才保存。这样即使用户关闭标签页或跳转，也更有机会保留最近输入。beforeunload 适合在有未保存编辑时提示用户，但事件触发不保证覆盖崩溃、进程被系统终止、移动设备被强制关闭等情况。

简单的自动保存示例：

<textarea id="draft" rows="6" cols="40"></textarea>
<button id="clearDraft" type="button">清除草稿</button>

<script>
  const DRAFT_KEY = "demo:draft:v1";
  const draft = document.querySelector("#draft");

  try {
    draft.value = sessionStorage.getItem(DRAFT_KEY) || "";
  } catch (error) {
    console.error("读取草稿失败：", error);
  }

  draft.addEventListener("input", () => {
    try {
      sessionStorage.setItem(DRAFT_KEY, draft.value);
    } catch (error) {
      console.error("保存草稿失败：", error);
    }
  });

  document.querySelector("#clearDraft").addEventListener("click", () => {
    draft.value = "";
    try {
      sessionStorage.removeItem(DRAFT_KEY);
    } catch (error) {
      console.error("清除草稿失败：", error);
    }
  });
</script>

如果保存频率较高，可以对输入事件做防抖，减少写入次数；对很大的内容，则应考虑 IndexedDB 或服务端草稿，并处理保存失败、版本升级和过期清理。使用 localStorage 保存长期草稿时，用户共享设备、退出登录和账号切换都需要纳入清理设计。

七、SPA 中的刷新与状态恢复

单页应用（SPA）中的路由切换通常不会重新加载整个文档，因此组件状态可能在应用运行期间保留。直接刷新某个前端路由则会让浏览器向服务器请求该路径；服务器必须配置为正确返回应用入口文件，否则可能出现 404。刷新后，内存中的状态仍会重置，需要从 URL、Storage、服务端或重新请求的数据中恢复。

建议把状态按用途放置：

• 当前路由、可分享的筛选条件：URL。
• 短期草稿或标签页内的临时状态：sessionStorage。
• 跨访问保留的非敏感偏好：localStorage，并设计过期和清理。
• 需要跨设备同步、权限控制或可信保存的数据：服务端。

对 SPA 路由直接刷新返回 404，不是调用某个 JavaScript 刷新 API 能解决的问题。应检查 Web 服务器或托管平台的路由回退配置，同时确保静态资源路径正确。若是业务接口返回数据异常，则应先检查接口状态、部署版本和缓存响应，不要用刷新循环掩盖故障。

八、浏览器恢复、滚动位置与导航边界

浏览器可能自行恢复表单或滚动位置，也可能通过 bfcache 恢复整个页面。具体行为取决于浏览器、页面生命周期和导航方式，不应假定每次都会恢复或每次都会丢失。若页面使用自定义恢复逻辑，应测试刷新、后退、前进、重复打开标签页和移动端场景，避免与浏览器自带行为相互覆盖。

可以监听 pageshow 来观察页面是否从 bfcache 恢复：

window.addEventListener("pageshow", event => {
  if (event.persisted) {
    console.log("页面由浏览器的页面缓存恢复");
  } else {
    console.log("页面正常显示");
  }
});

event.persisted 表示这次展示是否来自 bfcache，但不同浏览器和页面条件会影响是否进入该缓存。它不是检测 HTTP 缓存的通用方法。如果恢复页面时需要重新校验数据，可以在这个事件中发起合适的请求，而不是无条件强制刷新。

若页面需要自己保存滚动位置，可以在离开页面前保存并在合适时恢复。不过浏览器可能也在管理滚动恢复，应用应避免重复设置导致跳动。以下是一个仅用于演示的会话级方案：

const SCROLL_KEY = "demo:scroll:v1";

window.addEventListener("pagehide", () => {
  try {
    sessionStorage.setItem(SCROLL_KEY, String(window.scrollY));
  } catch (error) {
    console.error("保存滚动位置失败：", error);
  }
});

window.addEventListener("pageshow", () => {
  try {
    const value = Number(sessionStorage.getItem(SCROLL_KEY));
    if (Number.isFinite(value) && value >= 0) {
      window.scrollTo(0, value);
    }
  } catch (error) {
    console.error("恢复滚动位置失败：", error);
  }
});

实际应用中应只在确实需要时启用自定义滚动恢复，并考虑内容尚未加载完成、布局高度变化以及路由切换等因素。也可以通过 history.scrollRestoration 管理部分浏览器的历史记录滚动恢复行为，但它不是所有页面状态的保存方案。

九、常见错误及其原因

1. 认为 location.reload(true) 一定清除缓存。该参数不是可靠的现代跨浏览器方案，也无法清除 Service Worker、CDN 或代理缓存。
2. 刷新时给 URL 加随机数，并对所有请求都这么做。这会制造大量不同 URL，损害缓存复用；应根据资源类型配置缓存策略，必要时才使用版本化地址。
3. 把清理 Storage 当作清理浏览器缓存。sessionStorage.clear() 和 localStorage.clear() 只影响相应来源的 Web Storage，不会清除 HTTP 缓存或 Service Worker 缓存。
4. 把 no-cache 理解为“绝不缓存”。它通常要求使用前验证；若确实要求不存储，应由服务器评估使用 no-store，而不是依赖前端猜测。
5. 把所有页面状态塞进 localStorage。这会造成过期数据、账号切换串数据、存储配额和安全问题。只保存必要数据，并定义键名版本、有效期和清理策略。
6. 保存状态却不做验证和异常处理。Storage 内容可能损坏、过期或被用户修改；解析后应校验结构和值，写入失败也应能优雅降级。
7. 将未可信内容通过 innerHTML 恢复到页面。客户端存储不是可信来源。展示文本时优先用 textContent，并按上下文进行适当处理。
8. 刷新失败后自动无限重载。可能造成循环请求和页面无法使用。应增加重试上限、等待时间和错误提示，并优先定位服务器或网络问题。
9. 只在 beforeunload 中保存数据。该事件不保证在所有终止场景都可靠触发。重要草稿应按输入持续保存，或使用服务端保存。

十、按目标选择方案

结语

处理刷新问题时，先区分资源缓存和页面状态：资源是否更新，主要看 HTTP 响应头、文件版本、Service Worker 和部署缓存；状态是否保留，主要看它保存在哪里，以及刷新后如何恢复。普通刷新使用 location.reload()，不要依赖过时的强制刷新参数；需要保留的状态则根据是否要分享、保存多久和是否敏感，选择 URL、sessionStorage、localStorage 或服务端。把缓存策略放在正确的层处理，通常比不断刷新或清空所有存储更安全、可控，也更容易排查。