打开浏览器控制台，Network 里/api/user/login返回 200，token 也拿到手了，可页面就是赖在主界面上不动，或者刚跳过去又被弹回来——这是我陪朋友调黑马点评 P30 那段登录逻辑时最常见的一个场景。围绕 redis、黑马点评、login、前端、跳转这几个关键词，我把这套登录跳转链路从头到尾捋一遍，说说为什么改了前端代码还是解决不了问题，以及真正该从哪里下手。这篇内容适合正在做黑马点评项目的同学、刚接触前后端联调的后端开发者，以及被"登录后不跳转"卡了半天的人。不讲虚的，从数据流、Redis 键值设计、拦截器放行、nginx 部署到缓存排查，一条一条拆开。
1. 先把这条登录链路完整走一遍，别急着改代码
遇到跳转不对，很多人的第一反应是打开login.html找那一行location.href改掉。改完刷新，还是老样子，于是怀疑人生。问题在于，跳转只是整条链路的最后一环，前面任何一环断了，最终表现都是"页面不动"。所以先把链路画清楚，再谈改哪儿。
1.1 从输入手机号到页面跳转，中间到底发生了什么
黑马点评的登录是典型的短信验证码登录，不涉及密码。整个流程按时间顺序拆开，大概是这样几步。
第一步，用户在登录页填手机号，点"发送验证码"。前端发一个 GET 或 POST 请求到/api/user/code?phone=138xxxxxxxx。后端UserController收到后生成一个 6 位随机数字，把它写进 Redis，键是login:code:加上手机号，值是验证码字符串，同时设置 2 分钟的过期时间。这里必须有过期时间，不然验证码永久有效，安全性就没了。
第二步，用户把收到的验证码填进输入框，点登录。前端发 POST 请求到/api/user/login，请求体里带着手机号和验证码两个字段。
第三步，后端拿到手机号和验证码，先去 Redis 里按login:code:加手机号的键把之前存的验证码取出来，和用户提交的比对。不一致直接返回失败；一致的话，再去数据库按手机号查用户，查不到就自动注册一个新用户。
第四步，后端给这次登录生成一个 token，通常是一个 UUID 字符串，然后用login:token:加这个 token 作为键，把用户信息存进 Redis，同时设置 30 分钟的过期时间。最后把这个 token 返回给前端。
第五步，前端拿到响应里的 token，存进浏览器的存储里（黑马点评用的是 sessionStorage），然后执行跳转，跳到信息页或者用户中心页。
第六步，之后的每一个请求，前端都要在请求头里把这个 token 带上，通常放在authorization字段。后端有两层拦截器：第一层负责从请求头取 token、去 Redis 查、查到就把用户信息放进 ThreadLocal 并刷新有效期；第二层判断 ThreadLocal 里有没有用户，没有就直接返回 401。
看清楚了吗，从点击登录到页面跳转，横跨了浏览器存储、HTTP 请求、Redis 读写、拦截器放行四个环节。任何一环出问题，用户看到的现象都一样：点了登录，页面没去该去的地方。
1.2 三层结构里，哪一层最容易出问题
把上面六步按职责归类，可以分成三层：前端层（存储 token、带 token、跳转）、网关层（nginx 转发、路径匹配）、后端层（Redis 读写、拦截器判断）。
按我实际帮人排查的经验，出问题概率从高到低排是：前端层 > 网关层 > 后端层。原因不复杂——后端代码是跟着视频一行一行敲的，逻辑相对固定；nginx 配置是复制粘贴的，改动少；而前端是最容易"我以为改了但没生效"的地方，缓存、部署目录、存储域，全是坑。
举个最常见的例子：有人在 IDE 里打开了前端源码工程，改了login.html里的跳转地址，保存，刷新浏览器，发现没变化。为什么？因为他 nginx 部署的是另一份静态文件，IDE 里那份源码根本没被 nginx 加载过。这种情况，改一百遍源码也没用。
还有一种，跳转地址没错，但 token 没存进去，或者存进去了没带上，后端拦截器判定未登录返回 401，前端响应拦截器一看 401 就跳回登录页。用户感觉就是"点登录没反应"，实际上是被拦回来了。
所以我的建议很直接：在动任何一行代码之前，先打开浏览器开发者工具的 Network 面板，把登录请求的请求头、响应体、状态码完整看一遍。这一分钟的花费，能省掉后面几小时的瞎改。
2. Redis 在这套登录体系里究竟存了什么
很多人把 Redis 当成一个"存验证码的地方"，其实它承担了整个会话管理的职责。黑马点评把登录状态放在 Redis 而不是传统的 HttpSession，核心原因是水平扩展——多台服务器共享同一份会话数据，谁都能校验。理解了 Redis 里存了什么，才能判断问题出在读写还是在传递。
2.1 验证码的键值设计与过期时间
验证码这块的设计非常朴素，键是login:code:拼接手机号，值就是那串 6 位数字，过期时间 2 分钟。之所以用字符串而不是哈希结构，是因为只有一个值，没必要做成哈希。
这里有几个细节值得说。一是过期时间的单位，用RedisTemplate的opsForValue().set(key, value, timeout, TimeUnit)时，时间单位要写清楚，我见过有人写TimeUnit.SECONDS结果传了个 120 以为是 120 秒，其实想的是 2 分钟，这没错，但也有人传 2 配上SECONDS，那就变成 2 秒，用户还没输完就过期了。
二是键的命名前缀。加上login:code:是为了和其他业务数据区分开，用冒号分层是 Redis 社区约定俗成的做法，好处是在可视化工具里能按前缀折叠查看，一眼就知道哪些键属于同一类业务。
三是校验之后要不要删。严格来说，验证码用过一次就该删掉，防止重放。你可以校验通过后顺手delete一下，也可以用getAndDelete这类原子操作。视频里可能没强调，但这是个好习惯。
如果你在登录时反复收到"验证码错误"，先别怀疑代码逻辑，打开 Redis 客户端查一下这个键在不在、值是什么。键不存在通常意味着写入失败或已过期，键存在但值不匹配通常是读取的键拼错了——比如手机号前面多带了区号。
2.2 token 会话与 ThreadLocal 的配合
token 这块是登录的核心。后端生成一个 UUID 作为 token，把用户信息（一般是脱敏后的 UserDTO，只含 id、昵称、头像这些）序列化后存进 Redis，键是login:token:加 UUID。
为什么不用 JWT 而用 Redis 存？因为 Redis 里的数据是可以主动失效的。用户登出、管理员踢人、会话超时，删掉那个键就完事了。JWT 一旦签发，在过期前很难撤销，除非再维护一份黑名单，反而更麻烦。
请求进来时，第一层拦截器RefreshTokenInterceptor负责把 token 换成用户。它从请求头authorization取出 token，拼上login:token:去 Redis 查，查到了就反序列化成 UserDTO，塞进UserHolder（内部就是个 ThreadLocal），同时把键的过期时间重新设为 30 分钟——这就是"滑动过期"，用户只要在活跃，登录状态就一直续着。
用 ThreadLocal 的原因是：一次请求就是一个线程，把用户数据挂在当前线程上，后面的 Controller、Service 层想用直接UserHolder.getUser()拿，不用层层传参。但要注意，请求结束后一定要在拦截器的afterCompletion里调用remove()清理，否则线程池复用线程时，上一个用户的身份可能被下一个请求读到，这是很隐蔽的串号问题。
第二层LoginInterceptor只做一件事：看 ThreadLocal 里有没有用户，没有就返回 401。它拦的是需要登录的接口，登录、发验证码这类接口必须放行。
2.3 序列化配置：一个让登录接口直接 500 的坑
这里插一个高频事故。用RedisTemplate存 UserDTO 时，如果不做序列化配置，默认用的是 JDK 序列化，要求对象实现Serializable接口。UserDTO 没实现的话，直接抛异常，登录接口 500。
更麻烦的是，JDK 序列化写进去的内容在 Redis 客户端里看是一堆乱码，排查时完全看不出存了什么。所以标准做法是配置成 JSON 序列化：
@Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(factory); // key 用 String 序列化，方便在客户端里阅读 template.setKeySerializer(RedisSerializer.string()); template.setHashKeySerializer(RedisSerializer.string()); // value 用 JSON 序列化，避免乱码，也避免强制实现 Serializable GenericJackson2JsonRedisSerializer jsonSerializer = new GenericJackson2JsonRedisSerializer(); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; }配上 JSON 序列化之后，你在 Redis 客户端里能看到{"id":1,"nickName":"user_xxx","icon":""}这样的内容，排查起来一目了然。这个配置建议一开始就做好，别等出问题再回头补。
3. 前端跳转的正确写法，以及大多数人写错的地方
前端这部分是整个问题的重灾区。不是说代码难，而是它涉及的环节多——存哪里、怎么带、什么时候跳，每一步都有讲究，写错任何一处，表现都是"跳不过去"。
3.1 请求拦截器：token 靠它送出
前端登录成功后，token 存在浏览器里。之后每个请求，都要把它塞到请求头。分散在每个请求里手动加显然不现实，所以用 axios 的请求拦截器统一处理：
axios.interceptors.request.use( config => { // 从 sessionStorage 取，注意键名要和登录时写入的一致 const token = sessionStorage.getItem("token"); if (token) { config.headers['authorization'] = token; } return config; }, error => Promise.reject(error) );这段代码有两个容易翻车的点。
第一个是键名。登录时写的是"token"，这里读的也必须是"token"，大小写、拼写完全一致。我见过有人写入用"Token"，读取用"token"，结果永远取不到，后端永远判定未登录。
第二个是是否真的执行了这段拦截器。如果这段代码写在某个页面单独引用的 JS 文件里，而你在另一个页面发的请求，拦截器根本没挂上去。所以拦截器配置通常放在全局的 JS 里，所有页面都引入。
还有一点，如果你用sessionStorage，那是按标签页隔离的，同一个标签页内跳转没问题；但只要换了标签页，token 就没了。用localStorage的话跨标签页共享。黑马点评用的是前者，所以在别的标签页打开时确实是未登录状态，这属于设计如此，不是 bug。搞不清这一点的人，会误以为登录失效了。
3.2 响应拦截器：401 的处理要克制
响应拦截器里最常写的一段逻辑就是：收到 401 就跳登录页。逻辑本身没错，但写法上有个坑——它会拦截所有响应，包括登录请求本身的响应。
设想一下：登录接口因为某种原因返回了 401（比如路径放行没配好，登录接口被拦截器拦了），响应拦截器立刻把页面跳到登录页。用户看到的就是"点了登录，页面闪了一下，还在登录页"，感觉像没反应。更糟的是，如果登录页本身也有请求触发 401，就可能形成循环跳转。
我的写法是这样，加一层排除：
axios.interceptors.response.use( response => response, error => { if (error.response && error.response.status === 401) { // 登录接口自身的 401 不在这里处理，交给调用方 const url = error.config && error.config.url; if (url && !url.includes('/user/login')) { location.href = '/login.html'; } } return Promise.reject(error); } );这样一来，登录接口的错误能正常抛出，你在.catch里能打印出真实原因，而不是被默默跳转掩盖掉。调试阶段，把跳转逻辑写保守一点，比写得激进要好得多。
3.3 登录成功后的跳转分支怎么写
登录成功后的处理，通常是这样的：
axios.post('/api/user/login', { phone: this.phone, code: this.code }).then(res => { if (res.data && res.data.success) { sessionStorage.setItem("token", res.data.data); location.href = "/info.html"; } else { alert(res.data ? res.data.errorMsg : "登录失败"); } });这段里有两个细节容易错。一是响应结构的层级。黑马点评后端统一返回一个 Result 对象，形如{success: true, data: "token字符串", errorMsg: null}。真 token 在res.data.data里，不在res.data里。直接存res.data的话，存进去的是整个对象，序列化成[object Object]，后端拿这个当 token 查 Redis 必然查不到，然后 401，然后被弹回登录页。
二是跳转的目标地址。有人写location.href = "/"，那自然回到主界面，看起来就是"一直跳主界面"。需求如果是登录后进用户中心，地址就得写对应的页面。先确认你跳的目标是不是你想要的，再去怀疑代码有没有生效，顺序别搞反。
4. 改了代码仍然跳主界面，按这个顺序排查
前面铺垫了原理，现在进入正题：为什么你改完代码，行为还是老样子。我按命中率排了个序，从最可能的开始查。
4.1 第一嫌疑：缓存与部署目录
这是最常见的两类情况，我把它俩放一起说，因为表现几乎一样。
先说部署目录。黑马点评的前端通常由 nginx 托管，静态文件放在 nginx 的html目录下，比如/usr/local/nginx/html/hmdp/。但很多人在 IDE 里打开的是另一份前端源码，改的是源码里的文件。nginx 加载的永远是它自己那份，你改源码，它纹丝不动。判断方法很简单：把 nginx 部署目录下的 login.html 打开看一眼，看你修改的那行代码在不在。不在，就是改错文件了。
再说缓存。即使改对了文件，浏览器也可能加载的是缓存版本。强制刷新（Windows 上是 Ctrl + F5，Mac 上是 Cmd + Shift + R）可以绕过。如果还是不行，考虑在 nginx 里给 html 加禁止缓存的响应头：
location ~* \.html$ { root /usr/local/nginx/html/hmdp; add_header Cache-Control "no-store, no-cache, must-revalidate"; add_header Pragma "no-cache"; }no-store表示完全不缓存，调试阶段用起来最省心，上线前再按需调整成缓存策略。另外，改了 JS 文件后，如果页面里引用的是xxx.js?v=1这种带版本号的写法，也要把版本号改一下，否则浏览器会继续用旧的。
4.2 第二嫌疑：后端拦截器与路径放行
如果 Network 里看到登录请求本身返回 401，那问题不在前端。检查拦截器注册时放行了哪些路径：
@Override public void addInterceptors(InterceptorRegistry registry) { // 第一层：拦截所有请求，负责刷新 token 有效期 registry.addInterceptor(new RefreshTokenInterceptor(stringRedisTemplate)) .addPathPatterns("/**").order(0); // 第二层：只拦需要登录的路径，登录相关一律放行 registry.addInterceptor(new LoginInterceptor()) .excludePathPatterns( "/user/code", "/user/login", "/blog/hot", "/shop/**", "/shop-type/**", "/upload/**", "/voucher/**" ).order(1); }两个注意点。一是放行路径的写法，要和实际请求路径完全对应。前端请求的是/api/user/login，nginx 转发时会去掉/api前缀（取决于proxy_pass的写法），后端实际收到的是/user/login。如果你在放行列表里写/api/user/login，那是匹配不上的。
二是两层拦截器的顺序。RefreshTokenInterceptor必须排在前（order 小），先把用户塞进 ThreadLocal，后面的LoginInterceptor才有东西可判断。顺序反了，LoginInterceptor 永远看到空值，所有请求全 401。这个顺序问题排查时很容易忽略，因为它不报错，只是静默地拦截了一切。
4.3 第三嫌疑：存储域不一致导致 token 丢失
这个坑比较隐蔽。浏览器存储是按域隔离的，localhost和127.0.0.1在浏览器眼里是两个不同的域，它们各自的 sessionStorage 互不相通。
典型场景：你用http://localhost:8080打开登录页，登录成功，token 存进去了。然后页面跳转或者你自己改成http://127.0.0.1:8080/info.html访问，这时候读 sessionStorage 是空的，因为换了域。表现就是一直跳回登录页。
解决办法就是全程使用同一个域访问，别混着用。改代码时如果动了地址栏的写法，顺手检查一下是不是统一了。
顺带提一句端口。如果页面由 nginx 的 8080 端口提供，而某些请求直接打到后端的 8081 端口，那就是跨域请求。跨域下如果后端没配 CORS，或者配了但没允许authorization头，token 也传不过去。黑马点评的推荐做法是通过 nginx 反向代理把/api转发到后端，让前端始终同源访问，从根上避免跨域问题。
4.4 第四嫌疑：nginx 代理配置
反向代理这段配置，重点是搞清楚proxy_pass结尾有没有斜杠，这决定了路径前缀会不会被去掉。
server { listen 8080; server_name localhost; # 静态页面 location / { root /usr/local/nginx/html/hmdp; index index.html; } # 接口反向代理到后端 location /api { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里的写法是proxy_pass http://127.0.0.1:8081;，结尾没有斜杠，所以前端请求的/api/user/login会被原样转发到后端，即/api/user/login。如果你写成http://127.0.0.1:8081/（结尾带斜杠），nginx 会把location匹配到的/api部分替换掉，转发成/user/login。
这两种写法都对，但要和后端的接口路径、拦截器放行路径保持一致。三种东西对不上，就会出现"请求 404"或者"请求被拦截"的情况。排查时，看 nginx 的access.log和error.log最直接，里面能看到实际转发到了哪里。
改完配置记得nginx -s reload，不然改动不生效——这也是一个"改了没反应"的经典来源。
5. 一次真实排查的完整记录
上个月帮人看这个问题的全过程，我原样记下来，你可以照着走一遍。
5.1 打开 Network 面板，盯住四个关键点
第一步永远是看请求。按下 F12 切到 Network，勾上 Preserve log（保留日志），因为跳转会导致请求记录被清空，不勾的话你什么都看不到。然后走一遍登录流程，重点看两个请求。
看/api/user/login这个请求。检查四件事：状态码是不是 200；请求体里 phone 和 code 有没有正确带上；响应体里的 data 字段是不是一串 UUID；响应头有没有异常。
再看登录之后紧接着发出的那个请求，比如进信息页时查用户信息的请求。看它的请求头里有没有authorization，值是不是刚拿到的那个 UUID。如果这个头压根没有，问题就在请求拦截器；如果有但后端返回 401，问题在 Redis 或拦截器放行。
我当时看到的实际情况是：登录请求 200，响应体正常返回了 token；但后续请求的请求头里没有authorization，后端返回 401，响应拦截器跳回登录页。定位完成，问题在前端带 token 的环节。
5.2 动手改：login.html 与 axios 配置
打开 nginx 部署目录下的 login.html，发现存储 token 那行写的是：
sessionStorage.setItem("Token", res.data.data);而 axios 拦截器里读的是sessionStorage.getItem("token")，大小写不一致，永远读不到。把写入改成小写，重新加载页面（Ctrl + F5），再试一次。
同时我还顺手核对了响应结构的取值层级，确认res.data.data是对的，没有取错层。另外把跳转地址从location.href = "/"改成location.href = "/info.html"，因为需求本来就是登录后进信息页，原来那个写法虽然"能跳"，但跳的地方不对，也是"一直跳主界面"的一种来源。
5.3 后端放行与拦截器调整
顺带检查了一下后端的拦截器配置，确认/user/login和/user/code都在放行列表里，且两层拦截器的 order 顺序正确。这一步没发现问题，但值得每次都过一遍，因为它是 401 问题的另一个主要来源。
另外一个细节是 ThreadLocal 的清理。我在RefreshTokenInterceptor的afterCompletion里确认了有UserHolder.removeUser()这一行。没有的话，在高并发下可能出现用户身份串号，虽然不影响跳转，但属于必须补上的隐患。
5.4 验证：怎么确认真的修好了
修完别只看"能跳了"，要做完整验证。第一步，清空浏览器缓存和 sessionStorage，从头走一遍登录，确认能跳转。第二步，登录后刷新页面，确认登录状态还在（说明 token 存住且 Redis 里的会话有效）。第三步，在 Redis 客户端里查login:token:开头的键，确认存在且 TTL 在 30 分钟以内。第四步，退出登录后再点需要登录的页面，确认能正确跳回登录页。
四步都通过，才叫真的修好了。只验证第一步，很容易漏掉过期时间、登出清理这些没写对的情况。
6. 常见问题速查与踩坑清单
把上面散落的知识点整理成表格，出问题时对着查会快很多。
6.1 症状与原因对照表
| 现象 | 最可能的原因 | 快速验证方式 |
|---|---|---|
| 点登录没反应，页面不动 | 登录请求 401，被响应拦截器跳回登录页 | Network 看登录接口状态码 |
| 登录成功但立刻被弹回登录页 | 后续请求未携带 token，或 token 键名不一致 | 看后续请求头是否有 authorization |
| 改了代码毫无变化 | 改的是源码不是 nginx 部署目录，或浏览器缓存 | 直接打开部署目录文件核对内容 |
| 一直跳到主界面 | 跳转地址写成/，或跳转逻辑未生效 | 搜索页面里所有 location.href |
| 后端日志显示查不到用户 | Redis 里 token 键不存在，或 key 前缀拼错 | Redis 客户端 keys login:token:* |
| 登录接口直接 500 | Redis 未启动，或序列化配置缺失 | 看后端异常堆栈和 Redis 连接状态 |
| 换标签页就变成未登录 | sessionStorage 按标签页隔离，属正常行为 | 改成 localStorage 或同标签页操作 |
| 所有接口全 401 | 两层拦截器 order 顺序反了 | 检查拦截器注册代码里的 order 值 |
6.2 几条用血换来的经验
第一条，调试阶段把跳转逻辑全部注释掉，改成打印日志。那些自动跳转的代码在排查时是纯粹的干扰项，它会把真实错误吞掉，让你误以为请求没发出去。等逻辑验证完了再把跳转加回来，效率能翻倍。
第二条，改前端代码之前，先在浏览器地址栏确认你访问的是哪个目录下的文件。我见过太多人在 IDE 里改了半天，结果发现 nginx 指向的是完全另一个路径。花十秒确认一次，比后面抓瞎半小时强。
第三条，Redis 的键名和前缀，用常量类统一管理。散在各处的字符串字面量，只要有一处拼写不一致，就会出现"写入成功但读不到"的诡异现象，而且这种问题不会有报错，只能靠肉眼比对，特别折磨人。
第四条，每次改完 nginx 配置一定 reload。nginx -s reload这条命令看着简单，但忘记执行的人真的不少，然后盯着没生效的配置怀疑人生。
第五条，浏览器开发者工具里的 Disable cache 选项，在 Network 面板打开时勾上。这样在前端调试期间，只要工具面板开着，就不会走缓存，省去反复强刷的麻烦。
第六条，关于 Redis 的 TTL 刷新逻辑，一定要注意只在查到用户后才刷新，查不到就别刷。有人写成无论查没查到都执行一次expire，在键不存在时虽然不会报错，但逻辑上是多余的，还容易掩盖键名写错的问题。
第七条，login.html和info.html这类页面里如果也做了登录状态判断，注意别和响应拦截器的 401 跳转叠加。两处都在跳，就会出现页面来回闪的情况。建议只保留一处的跳转职责，另一处只做静默处理。
第八条，如果你用的是RedisTemplate操作哈希结构存用户信息（有些实现用opsForHash存 UserDTO 的各个字段），取值时字段名要和存入时一致，尤其是驼峰和全小写的差异，这类错误同样不会报错，只会静默返回 null，然后你拿到一个字段全空的用户对象。
第九条，排查时善用 Redis 的monitor命令。它会把所有到达 Redis 的命令实时打印出来，你能清楚地看到后端到底有没有来查、用的是什么键、值对不对。这个命令对性能有影响，只在调试时短时间开一下就行。
第十条，也是最实在的一条：遇到"改了没生效"，先假设代码没被加载，而不是逻辑写错了。这个假设能帮你省下大量无效的代码审查时间。加载问题（目录、缓存、代理、版本号）在实际项目里出现的频率，远高于逻辑问题。
最后分享一个小习惯。我现在调这套登录流程时，会在 token 写入之后加一行console.log("token saved:", token)，在请求拦截器里加一行console.log("token sent:", config.headers['authorization'])。两个日志一对，token 是没存上还是没带上，一目了然。等联调稳定了再把这两行删掉。这两行打印值千金，比盯着代码猜快得多。至于后续还能怎么扩展，比如把 sessionStorage 换成带过期时间的前端存储封装、给拦截器加上请求重试，这些都可以在链路彻底跑通之后再慢慢折腾——但前提是，你得先把这条链路的每一环都看明白。
