今天有个实习生问我，老板让做个登录成功后跳转首页，他写了个 window.location.href = 'index.html'，然后跑过来问我这样行不行。我说行啊，咋不行？他一脸懵，说网上有人说这样不好，有安全隐患，还慢。

我差点把咖啡喷出来。这年头，连个跳转都要搞出这么多花架子？其实吧，大部分时候你确实不需要搞那么复杂。但既然你问了，我就跟你掏心窝子说说，到底啥时候该用啥，啥时候用了会坑爹。

首先，最粗暴也最常用的，就是 location.href。这玩意儿就像是你直接开车撞过去，不管前面是墙还是路，反正你就这么干了。优点？简单，谁都会。缺点？它会往历史记录里留一笔。

啥意思呢？就是你从A页跳到B页，用户在B页点浏览器的“后退”按钮，又能回到A页。这在很多场景下是好事，比如表单提交失败跳回上一页。但在某些场景下，比如支付成功页，你绝对不想让用户点后退回到支付页面再点一次支付，那财务系统要哭死的。

这时候，你就得用 location.replace。这招狠，它直接把当前页面从历史记录里抹掉，换上新页面。用户点后退，直接跳过你，回到你之前的那个页面。对于防止重复提交、防止敏感信息泄露，这招是标配。

还有个更隐蔽的坑，就是 window.location.assign。这俩货长得太像了，经常把人搞混。assign 也是加历史记录，跟 href 差不多，但语义上更明确，表示“我要加载一个新资源”。如果你在意代码的可读性，或者团队里有强迫症领导，用 assign 显得你更专业。

但是，兄弟们，别以为换了个属性就万事大吉了。真正的坑在后面。

你有没有遇到过，跳转的时候页面白屏好几秒？或者跳转后样式全乱了？这通常是因为你只改了 URL，没处理好资源加载的顺序。特别是在单页应用（SPA）里，如果你用原生 JS 做跳转，很容易出现路由冲突。

这时候，你就得考虑用 history.pushState 或者 history.replaceState 了。这俩是 HTML5 提供的 API，专门用来操作浏览器历史记录栈，而不刷新页面。听起来很高级对吧？确实，它能实现无刷新跳转，用户体验极佳。

但注意，这玩意儿不触发真正的页面跳转，它只是改变了 URL 和历史记录。如果你的后端没有做好路由配置，用户刷新页面，或者分享链接给别人，服务器找不到这个路由，直接 404。

我上次接手的一个老项目，就是前端用 pushState 做跳转，后端还是传统的 PHP 路由。结果用户分享链接后，打开全是空白页。排查了两天，最后发现是 Nginx 配置没加 fallback 规则。这种坑，新手根本想不到。

所以，总结一下。

如果你只是简单的静态页面跳转，或者后端路由很稳，用 location.href 完全没问题，别整那些虚的。

如果你要防止用户后退导致重复操作，比如支付、提交表单，必须用 location.replace。

如果你在搞 SPA 或者需要精细控制历史记录，比如侧边栏导航不刷新主内容区，那就用 history.pushState。

别听那些大V瞎吹，说原生 JS 跳转过时了，要用 Vue Router 或者 React Router。工具是为人服务的，如果你的项目不需要复杂的组件通信，不需要状态管理，强行上框架就是过度设计。

最后，提醒一点，跳转前一定要做权限校验。别让用户直接通过修改 URL 进入后台管理页，这种低级错误，我在面试里见过太多。

js实现页面跳转 看似简单，实则暗藏玄机。选对方法，能省不少调试时间。选错方法，后期维护能让你头秃。

希望这点经验能帮到你，少走点弯路。毕竟，代码是写给人看的，顺便给机器执行。别为了炫技，把自己绕进去。