navigator 不能用于页面跳转，因其是只读对象，仅提供浏览器信息，无跳转方法；正确方式是使用 window.location.href、replace 或 assign，或 SPA 场景下的 history.pushState/replaceState。
不靠谱，navigator 本身不是跳转 API，直接用它做页面跳转是误解，多数情况下会失败或无响应。
为什么 navigator 不能用来跳转
navigator 是只读对象，提供浏览器信息（如 navigator.userAgent、navigator.onLine），没有 go()、to() 或类似跳转方法。常见误写如 navigator.href = 'xxx' 或 navigator.redirect('xxx') —— 这些在任何标准浏览器中都不生效，也不会报错，只是静默忽略。
- 查 MDN 或 WHATWG 规范，
navigator接口定义里确实没有跳转能力 - 混淆来源常是把
window.location或history的方法记成了navigator - 某些老旧 Cordova/WebView 插件曾暴露自定义
navigator.xxxJump，但属非标扩展，不可移植
window.location 是最直接可靠的跳转方式
它是标准、跨浏览器、同步生效的跳转入口，适合绝大多数「立刻离开当前页」场景。
-
window.location.href = 'https://example.com'：最常用，等价于用户点击链接 -
window.location.replace('https://example.com')：替换当前历史记录项，用户点返回不会回到原页 -
window.location.assign('https://example.com')：语义更明确，行为同href =赋值 - 注意：赋值必须是完整 URL（含协议）或相对路径；仅传
'page.html'依赖当前 base URL
history.pushState() 和 replaceState() 适合单页应用（SPA）
它们不触发页面重载，只更新地址栏和 history 栈，需配合前端路由手动渲染内容。
立即学习“前端免费学习笔记（深入）”；
-
history.pushState({page: 1}, '', '/new-path')：添加新记录，用户可后退 -
history.replaceState(...)：修改当前记录，不增加历史长度 - 缺点：URL 变了但页面没刷新，如果服务端没配 fallback（如 Nginx 的
try_files），直接访问该 URL 会 404 - 必须监听
popstate事件来响应浏览器前进/后退
容易被忽略的关键细节
跳转是否成功，不仅看 JS 是否执行，还要看上下文安全限制和用户意图：
- 在 iframe 中调用
window.location跳转，受sandbox属性和X-Frame-Options影响，可能被阻止 - 部分浏览器（如 iOS Safari）禁止在非用户手势（如
setTimeout、fetch回调）中触发跳转，会静默失败 -
location.replace()在调试时难追踪，因为原页面记录被抹除，DevTools 的 Network / Console 可能清空 - SEO 友好性：服务端跳转（301/302）比 JS 跳转更利于爬虫识别，后者依赖执行环境
