为何修改window.location.href无法起到return作用终止后续代码？

很多开发者对这个操作的认知有个普遍误区：觉得给window.location.href赋值的瞬间，浏览器就会立刻像return/throw一样，把当前JS执行流掐断、销毁页面上下文，根本不会跑后面的代码。
但完全不是——按照浏览器的标准实现，这个赋值操作仅仅是给「页面卸载跳转流程」排了一个异步宏任务，全程不会打断当前正在执行的同步JS栈。

你的示例代码的完整执行路径 #

逐行拆解实际发生的事：

• 第一行给window.location.href赋值为http://example.com/时，浏览器只是把这个地址暂存到内部的待跳转队列里，完全不会执行实际的页面切换动作，JS执行流直接往下走
• 下一行的console.log('does it log?')会正常执行，控制台必然能看到日志输出
• 再下一行把href赋值为http://example.org时，浏览器会直接更新暂存的待跳转地址，把之前存的example.com地址直接覆盖掉
• 等整个同步执行栈里的代码全部跑完、所有微任务都处理完毕，浏览器才会正式启动跳转检查流程：
  1. 先检查页面有没有注册beforeunload回调，需不需要弹确认框让用户选择“离开/留在当前页”
  2. 如果用户确认离开，才会真正销毁当前DOM上下文、终止未完成的XHR/fetch请求、拉取新页面资源
  3. 如果用户选择留在当前页，之前暂存的跳转地址直接作废，页面所有交互逻辑完全不受影响

这也是为啥最终实际跳的是example.org——浏览器永远只认同步栈跑完后，最后一次设置的跳转目标。

为啥浏览器不把跳转做成立刻中断的同步操作？ #

这个设计从根上是为了兼容用户交互逻辑：

如果真的在你给href赋值的瞬间就立刻掐断所有JS执行、销毁页面上下文，那当页面触发beforeunload确认弹窗、用户点了“留在当前页”的时候，已经被销毁的JS执行上下文根本没法恢复，整个页面会直接变成无响应的死页。

本质上，从你给href赋值，到真正开始切走页面，中间存在一段完全透明的窗口期：这段时间里你写的所有同步JS代码都会被正常执行，浏览器绝对不会插手打断执行流。

实际开发的注意事项 #

正因为跳转不会自动帮你终止后续代码，很多经典踩坑场景都是这么来的：

• 写未登录校验逻辑时，把跳登录页的代码写在前面，后面拿未登录权限调用敏感接口的代码还是会正常跑，甚至可能触发跨域或者权限报错
• 写表单提交逻辑时，提交成功后设置跳转，后面重复触发的表单校验逻辑还是会执行，甚至可能弹重复的错误提示

正确的写法是，设置完跳转之后必须手动中断后续执行，和普通的同步控制流逻辑保持一致：

// 错误写法：后续的敏感接口依然会正常执行
const checkLogin = () => {
  window.location.href = '/login';
  fetch('/admin/sensitive-api');
}

// 正确写法：手动return终止后续逻辑
const checkLogin = () => {
  window.location.href = '/login';
  return;
  fetch('/admin/sensitive-api');
}

哪怕你用window.location.replace()这类不写入浏览历史的跳转方法，也是完全一样的异步行为，不会帮你自动中断代码执行。

内容的提问来源于stack exchange，提问作者Balázs Herczeg