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。
