后端哥们甩过来一句“你前端自己处理跳转”，我就知道今晚又得跟 window.location 杠上了。成功登录成功后的后跳跳转，看着简单，登录实则藏着几个坑，成功踩过的后跳人自然懂。

最直白的登录写法，大家都见过：

fetch('/api/login',成功 {  method: 'POST', body: JSON.stringify({ user, pass}) }).then(res => res.json()).then(data => {  if (data.success) {  window.location.href = '/dashboard'; } });

这段代码能跑，但只能跑通最顺的后跳那条路。真实环境里，登录用户可能是成功在子页面被踢到登录框的，比如他正在编辑一篇长文章，后跳刚点保存，登录session过期，成功弹了个登录模态框。后跳登录成功后你还把他甩回首页？他刚写的三千字怕是要顺着网线来砍你。

这时候就得玩点花样了。登录前偷偷存一下当前路径，成功后再捞回来：

// 登录前 sessionStorage.setItem('redirectAfterLogin', window.location.pathname); // 登录成功后 const redirectTo = sessionStorage.getItem('redirectAfterLogin') || '/'; window.location.replace(redirectTo);

用 replace() 而不是 href，是为了不让浏览器历史里留下登录页的记录。用户点后退，不会鬼打墙似的又回到登录页，这细节，老测试会给你竖大拇指。

还有个场景，登录成功后带点参数过去，比如要自动填充用户名或者高亮某个模块。有人直接拼字符串：

window.location.href = '/dashboard?from=login&user=' + user.name;

看着没毛病，直到用户名里冒出个 & 或者中文。URL被截断、乱码，后台日志里一堆 %E4%BD%A0%E5%A5%BD 这种鬼东西。正确姿势是交给 URLSearchParams 处理：

const params = new URLSearchParams({ from: 'login', user: user.name}); window.location.href = `/dashboard?${ params.toString()}`;

要更精细一点，跳转前给用户个缓冲动画？我看过有些团队用个全屏遮罩，转个圈再跳，说是防用户手贱连点。其实防的是接口还没返回完就跳走，导致token没存上。真遇到慢网络，你直接跳，后面接口全401，那场面才叫尴尬。

存token也得看地方。有人图省事扔localStorage，刷新后还在，但XSS一打一个准。扔sessionStorage，关标签页就没了，适合那种“下次打开还得重新登录”的敏感系统。cookie得设HttpOnly，但前端就动不了了，得让后端set。这平衡，得跟后端对表，别自己瞎拍板。

最后说个偏门但实用的：跳转前把表单里密码字段清掉。不是浏览器自动填充那种，是内存里那个对象。有次我调试，控制台打印用户对象，密码明晃晃躺那儿，赶紧清了重来。虽然本地环境，但习惯养成，线上才不翻车。

所以啊，跳转这事，代码五分钟，思考两小时。路径、参数、存储、安全、体验，每个环节都对应一个真实踩过的坑。下次再有人让你“随便跳一下”，你可以把上面这几条甩他脸上。

(责任编辑：热点)