最简返回用<a href="#" onclick="history.back(); return false;">返回上一页</a>，浏览器原生支持、兼容性好；history.back()比document.referrer更可靠，因后者在跨域、隐私模式等场景常为空或失效。
用 history.back() 实现最简返回
直接在 index.html 里加一个点击就回退的链接，最轻量、兼容性最好。浏览器原生支持，不依赖服务器或历史栈长度判断。
- 写法：
<a href="javascript:history.back()">返回上一页</a> - 更稳妥的写法（避免某些旧版 Safari 对
javascript:协议的拦截）：<a href="#" onclick="history.back(); return false;">返回上一页</a> - 如果用户是从书签或新标签页打开
index.html，history.back()会静默失败（不报错，但无跳转），这是正常行为，无需额外处理
为什么不用 window.location.href = document.referrer？
document.referrer 看起来直观，但实际限制多，容易踩坑：
- 跨域页面、HTTPS → HTTP 页面、隐私模式下，
document.referrer可能为空字符串 - 用户从桌面快捷方式、邮件客户端、微信内嵌浏览器打开时，
referrer通常不可靠 - 即使有值，它只是字符串，不能保证该 URL 还有效（比如目标页已 404 或重定向）
-
history.back()是浏览器真实的历史操作，比拼接 URL 更符合用户预期
需要带参数或自定义跳转逻辑时怎么办？
如果业务要求「返回时刷新上一页」或「返回到某个固定路径」，就不能只靠 history.back()：
- 强制刷新上一页：
onclick="history.go(-1); location.reload(); return false;"—— 注意：这会触发两次加载，慎用 - 退回到指定页面（如首页）：
<a href="/"></a>，但这是「跳转」而非「返回」，会丢失历史栈中的中间页 - 更可控的方式是上一页传参，比如用
sessionStorage记录来源页：
sessionStorage.setItem('returnUrl', '/product/123');然后在index.html中读取并跳转：
<a href="#" onclick="location.href = sessionStorage.getItem('returnUrl') || '/'; return false;">返回</a>
移动端 WebView 里 history.back() 失效怎么办？
某些安卓 WebView（尤其老版本）或 iOS WKWebView 在特定配置下可能忽略 history.back()，这时要检查：
立即学习“前端免费学习笔记（深入）”；
- 是否启用了
setJavaScriptEnabled(true)（Android）或configuration.preferences.setValue(true, forKey: "allowFileAccessFromFileURLs")（iOS） - 是否在页面加载完成前就触发了
back()—— 建议加简单防抖：onclick="setTimeout(() => history.back(), 0); return false;" - 原生层是否拦截了 WebKit 的导航事件（如 iOS 的
decidePolicyForNavigationAction），这种情况下必须由原生侧提供返回接口供 JS 调用
history.back()；只有明确知道用户来源且需强控制跳转目标时，才引入 sessionStorage 或服务端传递的参数。别为了“看起来更智能”而增加 referrer 解析逻辑——它在真实场景中太不可靠。 
