history.back() 失败主因是浏览器历史栈不可靠，如 history.length≤1、replace跳转、SPA路由管理不当或WebView兼容问题；应先判断 history.length > 1 再回退，否则跳默认页。
直接用 history.back() 就能返回上一页，但多数情况下它会失败或跳错——根本原因不是写法不对，而是浏览器历史栈状态不可靠。
为什么 history.back() 点了没反应或跳到错误页面
这不是 JS 报错，而是浏览器 history 栈里没有“上一页”可退。常见于：
- 用户从书签、新标签页、微信内嵌浏览器直接打开当前页（history.length === 1）
- 页面通过
window.location.replace()跳转，覆盖了上一页记录 - 单页应用（SPA）中未正确管理 history（比如 React Router 用
replace: true） - 某些安卓 WebView 或 iOS 微信内置浏览器对
historyAPI 支持不一致
安全 fallback：先判断再回退，别硬调 history.back()
必须加一层保护逻辑，否则用户点完白屏或卡住。推荐写法：
function goBack() {
if (window.history.length > 1) {
window.history.back();
} else {
window.location.href = '/'; // 或你定义的默认首页
}
}
注意：window.history.length 是只读属性，表示当前会话中的历史条目数（含当前页），所以 > 1 才说明有上一页。
立即学习“前端免费学习笔记（深入）”；
比 history.back() 更稳的替代方案
如果业务允许，优先用显式跳转代替依赖历史栈：
- 后端渲染页面时，把来源 URL 存在
<input type="hidden" name="referer" value="...">或 data 属性里，JS 读取后window.location.href = referer - 前端路由场景（如 Vue Router / React Router），用
router.navigate(-1)（Vue Router 4）或navigate(-1)（React Router v6.4+），它们内部做了 history 状态校验 - 纯静态页想兼容微信，可加 query 参数标记来源：
index.html?from=list，点击返回时解析并跳指定页
别忽略移动端和 WebView 的特殊行为
微信 iOS 客户端、部分安卓厂商 WebView 对 history.back() 有拦截或延迟，尤其在页面包含 iframe 或调用了 pushState 后。实测发现：
- 微信中首次调用
history.back()可能触发“确认离开”弹窗（即使没监听beforeunload） - 某些 WebView 下
history.length始终为 1，必须依赖 referer 或 sessionStorage 缓存上一页路径 - 若页面是 PWA 或被添加到主屏幕，
history行为更接近原生 App，back()可能直接退出应用
真要兜底，就别只信 history —— 用户点击“返回”按钮那一刻，你手里得有至少一个可用的目标地址。
