location.replace 直接替换当前历史记录项，不新增历史条目，因此用户点击返回时跳过被替换页；它不触发 beforeunload、不保留滚动位置、受同源策略限制，且执行后后续 js 代码不再运行。
为什么 location.replace 不会留在浏览器历史里
因为 location.replace 会用新 URL **直接替换**当前历史记录项，而不是新增一条。用户点返回时，不会回到刚跳转前的页面，而是回到更早的那一页。这和 location.href = url 或 location.assign(url) 的行为有本质区别——后两者都会在 history stack 里多压入一项。
注意：它只影响当前 tab 的主文档 URL，不触发页面卸载事件（如 beforeunload），也不保留当前页的 scroll 位置（这点常被忽略）。
location.replace 的典型使用场景
适合用于登录成功后跳转首页、表单提交后重定向到结果页、或防止用户重复提交的“跳过中间页”流程。比如 OAuth 回调处理完 token 后，立刻 location.replace('/dashboard')，避免用户刷新或返回导致重复解析回调参数。
不适用于需要支持“返回上一步”的操作链路，比如多步表单中的“上一步”按钮不能靠它实现。
- ✅ 登录后跳转：
location.replace('/home') - ✅ 支付完成页跳转至订单详情：
location.replace(`/order/${id}`) - ❌ 不要用于“取消编辑”后想回列表页——用户点返回会跳过该列表页
常见错误：误以为能绕过安全限制或触发重载
location.replace 仍受同源策略约束，跨域调用会抛出 DOMException: Failed to execute 'replace' on 'Location'。它也不会强制触发页面 reload（除非目标 URL 和当前不同），也不会等待资源加载完成再替换——只要 URL 合法，替换立即发生。
容易踩的坑：
- 传入相对路径时，浏览器按当前 URL 解析，不是按 document base —— 比如当前是
/admin/users/123，执行location.replace('edit')会跳到/admin/users/edit，不是/admin/edit - URL 中含中文或特殊字符未编码，会报
URIError: malformed URI sequence，务必先encodeURIComponent参数部分 - 在 iframe 内调用时，只影响该 iframe 的 location，不是父页面
和 history.replaceState 的关键区别
location.replace 是全量 URL 替换，会触发新页面加载；history.replaceState 只改地址栏 URL 和 history state，不加载新资源，适合 SPA 中更新路由但不刷新页面。
如果只是想改 URL 又不想刷新，别用 location.replace —— 它做不到。反过来，如果希望彻底切断前后页的状态关联（比如清掉上个页面的临时 state、避免 back 时重新渲染旧数据），location.replace 就比 history.replaceState 更干净。
真正要注意的是：一旦用了 location.replace，当前页面 JS 执行环境就结束了，后续代码不会运行。所以别写成 location.replace(url); console.log('这里永远不会执行');
