前端页面为什么回退后表单还在：bfcache 缓存命中、pageshow 与状态清理

用户在订单筛选页填好日期和关键词，点进详情再按浏览器返回，筛选条件还在；但产品又要求“离开页面就清空”。这两件事并不矛盾：页面可能没有重新加载，而是从浏览器的 back-forward cache（bfcache）中整页恢复。先判断页面是否被缓存恢复，再决定清理时机，通常比盯着 localStorage 更快。

回退后表单还在，现场先看页面有没有重新加载

打开开发者工具的 Console，在页面入口和 pageshow 中分别打印日志：

console.log('script evaluated');

window.addEventListener('pageshow', (event) => {
  console.log('pageshow', {
    persisted: event.persisted,
    url: location.href
  });
});

从列表页进入详情，再返回列表。如果只看到一次 script evaluated，回退时出现 pageshow { persisted: true }，就说明浏览器恢复了原页面快照。输入框、滚动位置以及部分运行时状态都可能随快照一起回来。

为什么只写 window.onload 清理会失效

load 主要描述资源首次加载完成。bfcache 恢复时，浏览器不一定重新执行脚本和资源加载流程，因此下面这种写法只能覆盖首次打开：

window.addEventListener('load', () => {
  document.querySelector('#keyword').value = '';
});

这段代码在第一次加载时确实会清空输入框，但用户从详情页返回时通常不会再次触发你期待的初始化路径。这里先别急着把缓存禁掉，禁用 bfcache 会损失返回页面的速度和滚动位置恢复能力。

用 pageshow 区分首次进入和 bfcache 恢复

如果业务规则是“用户返回筛选页时清空”，可以把清理动作放在恢复分支。下面的示例只清空当前表单，不碰长期保存的用户偏好：

const filterForm = document.querySelector('#order-filter');

window.addEventListener('pageshow', (event) => {
  if (!event.persisted || !filterForm) {
    return;
  }

  filterForm.reset();
  filterForm.querySelectorAll('input[type="search"]').forEach((input) => {
    input.value = '';
  });
  console.log('filter reset after bfcache restore');
});

首次打开时 event.persisted 通常为 false，表单按正常默认值初始化；从历史记录恢复时才进入 reset()。如果筛选条件来自 URL 查询参数，还需要同步清理地址栏或重新解析参数，否则下一次渲染可能又把旧条件写回输入框。

pagehide 负责离开记录，别把它当成可靠的清理点

离开页面时可以用 pagehide 记录诊断信息，它在进入 bfcache 时也会触发：

window.addEventListener('pagehide', (event) => {
  console.log('pagehide', {
    persisted: event.persisted
  });
});

当 pagehide.persisted 为 true，页面可能只是暂时冻结，之后还会原样回来。若在这里无条件清空 DOM 或删除业务缓存，用户点击返回时可能遇到半截状态。需要退出即失效的短期数据，应在明确的恢复策略中处理；需要跨会话保留的内容则继续由 sessionStorage 或 localStorage 管理。

最后用四条路径验收状态策略

不要只在一次返回操作后下结论。至少按下面顺序验收：

1. 首次打开列表页，填入关键词，确认默认值和接口请求正常。
2. 进入详情页后点击浏览器返回，确认 Console 是否出现 persisted: true，并检查表单是否符合业务规则。
3. 在列表页刷新，确认刷新后的初始化逻辑与返回恢复逻辑没有混在一起。
4. 再执行前进、跨站跳转和移动端手势返回，观察是否有重复请求、焦点丢失或 URL 参数回写。

如果页面对恢复状态有明确要求，建议把“首次初始化”“bfcache 恢复”“显式刷新”分成三个可观察分支，日志里保留事件类型和当前 URL。这样出现“某个浏览器偶现表单不清空”时，能先判断是没有命中 bfcache，还是清理代码没有执行。

常见问题：bfcache 与表单状态怎么取舍

event.persisted 为 false 就一定没有恢复吗？

它是判断页面是否通过页面转换缓存恢复的重要信号，但不要把单个字段当作所有浏览器实现的唯一证据。还应结合页面日志、请求次数和实际导航路径判断。

能不能直接给页面加 no-store 禁用 bfcache？

可以作为特殊场景的兼容手段，但不应为了清空一个筛选框就全局牺牲返回性能。先把恢复分支写清楚，通常更容易保留浏览器的快照能力。

sessionStorage 会不会跟着 bfcache 一起恢复？

bfcache 恢复的是页面运行时快照，而 Web Storage 是另一个状态来源。实际表现取决于你的代码何时读取和写回存储，因此要分别记录快照恢复与存储读取日志。

为什么 reset 之后页面又出现旧关键词？

常见原因是路由参数、响应数据或框架状态在 reset 后再次渲染。清理表单时要同时检查 URL、状态管理层和异步请求的回填逻辑。

小结

浏览器回退后表单保留，首先要确认页面是否命中了 bfcache。用 pageshow 的 persisted 判断恢复场景，用 pagehide 记录离开事件，再把“返回是否清空”落实为明确的业务规则。保留缓存还是清理表单不是二选一，关键是让首次打开、缓存恢复和刷新各自有可验证的路径。