DevTools 登录态异常排查路线

按 DevTools 面板协作方式梳理登录态异常排查路径,覆盖 Cookie、Token、401、Storage 和安全策略检查。

#type / synthesis #status / growing #tech / dev / frontend #platform / browser #resource / chrome-devtools

[!info] related notes

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 不一定是“用户真的没登录”,也可能是刷新链路坏了
创建于 2026/4/13 更新于 2026/5/27