HTML5跳转无特有行为，实际差异源于浏览器对API实现的碎片化：iOS Safari限制pushState异步调用，Android WebView中replace()易丢Referer，Firefox禁用javascript:伪协议，WebView普遍不可靠beforeunload。
HTML5 的跳转行为本身没有“HTML5 特有跳转”，所谓“HTML5 跳转”实际是指现代 Web 开发中常用的几种跳转方式（window.location.href、location.assign()、location.replace()、 标签导航、history.pushState() 等）在不同系统+浏览器组合下的实际表现差异。这些差异不来自 HTML5 规范本身，而来自各浏览器对 DOM API、History API 和导航生命周期的实现细节与 bug 修复进度。
移动端 Safari 对 history.pushState() + popstate 的拦截很严格
iOS 15–16 的 Safari 在某些混合场景下会静默忽略 pushState() 调用，尤其发生在异步回调（如 fetch().then()）、定时器或用户手势未直接触发的上下文中。更麻烦的是，它可能不抛错，但后续 history.back() 或物理返回键失效。
- 必须确保
pushState()调用在用户可感知的同步事件内（如click、touchend），且不能被 Promise 链延迟 - 避免在
setTimeout(() => { history.pushState(...) }, 0)中调用 —— iOS Safari 会拒绝 - 检测是否生效：调用后立即读
history.state，若为null或未更新，说明被忽略 - 备用方案：降级使用
location.hash或显式location.assign()
location.replace() 在 Android WebView 中可能丢失 referer
部分 Android 系统（尤其是旧版 WebView 基于 Chromium 60–70）在调用 location.replace() 后发起的页面请求，Referer 请求头为空，导致后端权限校验失败或埋点丢失。
- 这不是所有 Android 浏览器都如此，但微信内置浏览器（X5 内核）、QQ 浏览器、部分厂商定制 WebView 普遍存在
-
location.assign()和直接点击通常保留 referer；replace()则大概率丢 - 若业务强依赖 referer（如 SSO 跳转、来源统计），应避免用
replace()做主跳转，改用assign()+ 手动清理 history（如需） - 无法绕过时，可将必要参数拼进 URL（如
?from=home），而非依赖 referer
Firefox 桌面版对 location.href = "javascript:..." 的限制最激进
Firefox 自 90+ 版本起默认完全禁用 location.href = "javascript:..." 这类赋值，即使内容是空函数（"javascript:void(0)"），也会抛出 SyntaxError: malformed URI sequence。
立即学习“前端免费学习笔记（深入）”；
- Chrome / Edge / Safari 仍允许（但已标记为 deprecated）
- 错误常出现在老代码或第三方 UI 库中，比如
- 修复方式：移除
href属性，或设为#，再用event.preventDefault()阻止跳转 - 更安全写法：
WebView 场景下 beforeunload 几乎不可靠
无论是 Android WebView 还是 iOS WKWebView，beforeunload 事件在页面跳转/关闭时触发概率极低，且无法弹出自定义提示（仅部分旧版 Android 支持原生确认框，但文案固定不可控）。
- WKWebView 自 iOS 9 起彻底屏蔽
beforeunload的提示能力；Android WebView 从 Chrome 50+ 开始也逐步阉割 - 该事件在 PWA 或全屏模式下同样失效，不是配置问题，是平台策略
- 如需用户确认离开，唯一可行路径是提前拦截跳转动作（例如监听
a点击、pushState前检查表单状态），并用模态框手动提示 - 不要依赖
beforeunload做关键数据保存 —— 它连触发都不能保证
真正影响跳转一致性的，从来不是 HTML5 标准，而是各端 WebView 内核版本碎片、系统级导航拦截策略、以及浏览器对“用户意图”的判定逻辑差异。实测中，最易踩坑的不是语法写错，而是把桌面端验证过的跳转链路，原样搬到微信或安卓厂商浏览器里运行 —— 那些看似“应该能行”的操作，往往在某个机型上静默失败，且无报错。
