DevTools 登录态异常排查路线
按 DevTools 面板协作方式梳理登录态异常排查路径,覆盖 Cookie、Token、401、Storage 和安全策略检查。
#type / synthesis
#status / growing
#tech / dev / frontend
#platform / browser
#resource / chrome-devtools
[!info] related notes
- 所属 MOC: 浏览器开发者工具 MOC, DevTools Network MOC, DevTools Application MOC
- 相关概念: Cookie 调试, 请求与响应检查, Storage 调试, Security / Issues 面板
- 易混淆概念: Cookie、Session、Token, Token 认证的实现流程
DevTools 登录态异常排查路线
范围
这条路线处理的是:
- 登录成功后下一次请求仍未认证
- 页面明明有登录态,但接口返回
401/403 - 多账号切换后状态串了
- Cookie / Token / Storage 的状态和请求表现对不上
为什么要放在一起理解
登录态问题最容易出现“本地看起来有值,但请求没带上”这种错觉。
它通常横跨三个层次:
- Network:请求和响应到底发生了什么
- Application:浏览器本地到底存了什么
- Security / Issues:浏览器策略有没有阻止它按预期工作
排查路线
第一步:先看请求到底带了什么
先开 Network 面板,重点看:
- 失败请求的状态码是不是
401/403 - Request Headers 里有没有
Authorization - 请求是否自动带上了 Cookie
如果连请求本身都没带上认证信息,先别急着看业务代码。
第二步:看响应有没有正确下发登录态
继续在 Network 看登录请求或刷新请求:
- 响应里是否有
Set-Cookie - 返回体里是否包含新的 access token / refresh token
- 跳转、代理或跨域流程有没有把关键头吃掉
这一层对应 请求与响应检查。
第三步:回到浏览器本地看是否真的存下来了
打开 Application 面板:
- Cookie 是否真的写进去了
- localStorage / sessionStorage 是否存在旧 token、旧用户信息
- 多套状态是否互相覆盖
这里要结合:
第四步:看是不是浏览器策略挡住了
如果“响应里下发了,Application 里也看到了,但请求还是没带上”,再看:
- 域、路径、过期时间是否正确
SameSite/Secure/ HTTPS 条件是否满足- 浏览器是否在 Issues / Security 中给了提示
第五步:最后才回到业务代码
只有当前四步证据都看清后,才回到代码排:
- 刷新 token 队列和重试逻辑是否有问题
- 请求拦截器是否没走到
- 登录成功后是否被旧状态覆盖回去了
对比与易混淆点
- Application 里看得到 Cookie,不代表请求一定会带上
- 请求没带 Token,不一定是后端问题,也可能是前端根本没写对本地状态
- 连续
401不一定是“用户真的没登录”,也可能是刷新链路坏了