使用pageshow事件 + ww.closeWindow：解决企业微信移动端OAuth2.0使用location.replace免密登录历史栈残留问题

问题背景：OAuth2.0 跳转与 history 栈污染

典型的 OAuth2.0 流程如下：

用户访问业务页面；
前端检测未登录，重定向到企业微信 OAuth 授权 URL；
用户在企业微信内完成授权；
企业微信回调到指定 redirect_uri，携带 code；
前端用 code 换取用户信息，完成登录。

为了防止用户手动刷新或后退时重复触发授权流程，很多开发者会使用 location.replace() 替代 location.href = ...，期望替换当前历史记录项，从而避免在浏览器 history 中留下“授权跳转页”。

但在移动端企业微信内置浏览器中，即使使用了 location.replace()，用户点击手机物理返回键时，依然会回到一个看似“空白”的中间页——实际上就是发起 OAuth 跳转前的那个页面（或跳转过程中的某个状态页）。这是为什么？

根本原因

企业微信移动端的 WebView 对 history.replaceState 和 location.replace 的实现存在差异，并不能完全清除或替换历史栈中的条目。此外，企业微信 OAuth 授权过程中涉及多个内部跳转（如 loading 页、授权确认页等），这些页面也会被压入 history 栈。最终导致：

用户完成登录后，history 栈中仍保留着授权前的页面；
当用户点击返回按钮时，会回退到那个“未登录状态”的页面，造成逻辑混乱或重复跳转。

更糟的是，这个“幽灵页面”可能处于缓存状态（bfcache, back-forward cache），即使它已经不再有效。

解决方案：利用 `pageshow` 事件检测缓存回退

HTML5 提供了一个不太为人熟知但非常有用的事件：pageshow。它会在页面每次显示时触发，包括从 bfcache 中恢复的情况。关键属性是 event.persisted：

如果 event.persisted === true，说明页面是从缓存中恢复的（即用户点了返回/前进按钮）；
如果为 false，则是正常加载。

结合这一特性，我们可以在用户从缓存回退到旧页面时，主动关闭企业微信窗口，从而避免停留在无效状态。

代码实现

以下是我们项目中的核心逻辑（已简化并注释）：

const WECOM_LOGIN_SUCCESS_CLASS = 'wecom-login-success';

// 判断是否已完成企业微信登录
export function isWecomLoginSuccess() {
  return document.head.classList.contains(WECOM_LOGIN_SUCCESS_CLASS);
}

// 登录前的准备：保存必要信息，并监听 pageshow
export function beforeWecomLogin() {
  if (isMobile()) {
    // 在移动端企业微信中监听 pageshow
    window.addEventListener('pageshow', function (event) {
      // 如果页面是从缓存恢复的，且当前未标记为登录成功
      if (event.persisted && !isWecomLoginSuccess()) {
        try {
          // 调用企业微信 JSAPI 关闭当前窗口
          ww.closeWindow();
        } catch (error) {
          console.error('Failed to close WeCom window:', error);
        }
      }
    });
  }
}

// 登录成功后，在 DOM 中打上标记
export function afterWecomLoginSuccess() {
  document.head.classList.add(WECOM_LOGIN_SUCCESS_CLASS);
}

工作流程

跳转前：调用 beforeWecomLogin()，注册 pageshow 监听器，并将必要参数存入 localStorage；
用户完成授权：回调页面执行 afterWecomLoginSuccess()，在 <head> 上添加 CSS 类作为“已登录”标记；
用户误点返回：
- 若回到的是未登录成功的旧页面，pageshow 触发且 event.persisted === true；
- 此时 isWecomLoginSuccess() 返回 false；
- 系统调用 ww.closeWindow() 主动关闭页面，避免用户停留在无效状态；
若用户正常刷新或重新进入：event.persisted === false，不会触发关闭逻辑。

为什么选择 `document.head.classList` 作为状态标记？

持久性：相比内存变量，DOM 状态在页面缓存恢复时依然存在；
简单可靠：无需依赖 localStorage 或 sessionStorage（可能被清理或跨域限制）；
隔离性好：仅作用于当前页面，不影响其他 tab 或会话。

当然，也可以结合 localStorage 存储时间戳或 token，但 DOM 标记在 bfcache 场景下更直接有效。

注意事项

仅在移动端启用：桌面版企业微信无此问题，且 ww.closeWindow() 在桌面端行为不同；
确保 JSAPI 已注入：调用 ww.closeWindow() 前需确保已正确注入企业微信 JS SDK；
兜底处理：捕获异常，避免因 JSAPI 不可用导致白屏；
不要滥用关闭：仅在确定是“无效回退”时才关闭，避免误杀正常用户操作。

总结

企业微信移动端 OAuth2.0 登录中的“幽灵页面”问题，本质是 WebView 对 history 管理的不一致性所致。通过监听 pageshow 事件并结合页面状态标记，我们可以在用户误触返回时优雅地关闭窗口，提供更流畅、安全的用户体验。

这种模式不仅适用于企业微信，对微信公众号、钉钉等类似封闭 WebView 环境也有借鉴意义。前端开发不仅要关注功能实现，更要深入理解运行环境的特性，才能写出真正健壮的代码。

提示：如果你正在开发企业微信应用，建议始终在真机上测试返回、刷新、锁屏等边缘场景——模拟器往往无法复现这些问题。

参考资料：

MDN: pageshow event
企业微信官方文档：JSAPI closeWindow
Web bfcache 机制详解

最后希望这篇博客能帮助你解决类似的坑！