针对你遇到的用户从订单汇总页返回至第三方支付页的问题，我整理了几个实用的前端和后端结合的方案，帮你实现拦截并跳转至指定页面的需求：

一、用history.replaceState修改历史记录（最推荐） #

浏览器的安全策略不允许直接删除历史记录，但我们可以替换历史栈中的第三方支付页条目，让用户点击返回时直接回到你指定的页面。

在你的订单汇总页面加载完成后，执行以下代码：

window.addEventListener('load', () => {
  // 将当前历史记录（即第三方支付跳转过来的那条）替换为目标页面URL
  history.replaceState(null, document.title, '/your-target-page');
});

这样操作后，用户点击返回按钮时，浏览器会加载你指定的/your-target-page，而不是第三方支付页。这个方案对用户体验影响最小，也符合浏览器的安全规范。

二、监听popstate事件拦截返回操作 #

通过监听浏览器的返回事件，判断用户是否要回到第三方支付页，再强制跳转至目标页面：

// 在订单汇总页面添加监听
window.addEventListener('popstate', (event) => {
  // 可以根据历史记录的state或跳转来源做判断
  // 例如：如果上一页是第三方支付域名，就拦截
  if (document.referrer.includes('third-party-pay-domain.com')) {
    event.preventDefault();
    window.location.href = '/your-target-page';
  }
});

⚠️ 注意：这个方案需要注意浏览器兼容性，部分浏览器可能不允许完全阻止默认返回行为，而且如果用户多次点击返回，可能会出现逻辑冲突，需要做好边界判断。

三、后端会话状态配合拦截（依赖第三方支付平台支持） #

如果第三方支付页允许与你的后端交互，可以通过会话标记来控制跳转：

1. 用户支付完成后，后端在会话中标记payment_completed = true；
2. 当用户意外回到第三方支付页时，第三方页的回调接口请求你的后端，后端检查会话状态，如果已完成支付，就返回跳转指令至你的目标页面。

不过这个方案的前提是第三方支付平台支持自定义回调或页面逻辑嵌入，否则无法实现。

关于session.onDestroy的补充 #

会话销毁后，用户的登录状态失效，但此时用户如果回到第三方支付页，前端无法直接拦截（因为会话销毁后前端可能无法感知）。这时候更依赖后端的校验：当第三方支付页发起请求时，后端检测到会话已销毁，直接返回跳转响应至目标页面。

关键注意点 #

• 同源限制：如果第三方支付页和你的页面不同源，前端无法直接操作第三方页的历史记录，只能在己方页面做处理；
• 安全优先：前端拦截只是辅助，后端必须做好支付状态的幂等性校验，避免用户重复支付或恶意操作；
• 用户体验：建议在订单汇总页清晰提示用户支付完成，引导用户进行后续操作（比如查看订单、继续购物），减少用户点击返回的概率。

内容的提问来源于stack exchange，提问作者Martin Fric