JWT 调试小细节及Apifox使用小技巧调接口时遇到一个有意思的现象我的博客项目有完整的双Token机制所以在调试工具Apifox里不做任何设置鉴权接口也能通以前写的都是双Token项目没怎么注意这件事这几天写了个单 Token 的项目调试没带 token 直接 401研究了一通才搞明白——差别就在「双 Token 会自动兜底单 Token 不会」。这篇正好讲讲这个顺便说说调试工具怎么正确带 token。双 Token 为什么「不带 token 也能通」单 Token 就必须带一、先记住一件事token 是放在「请求头」里的登录后后端发给你一个 token前端要把它存起来以后每次请求时放进请求头里带给后端后端验证通过才放行。这是所有鉴权的基本玩法。不管是单 Token 还是双 Token日常携带 token 的位置都是请求头。二、双 Tokenaccess 短效refresh 藏 Cookie 里兜底双 Token 设计里有两个 token分工不同作用有效期放哪access_token日常鉴权短比如 2 小时请求头refresh_token给 access 续命长比如 7 天Cookie浏览器自动带关键在 refresh_token 的存放位置——它在Cookie里。Cookie 的特点是浏览器以及 Postman / Apifox会自动帮你带上不用你写代码。三、核心双 Token 的「自动兜底」逻辑后端的鉴权中间件里有这么一段关键判断accessToken:从请求头取 refreshToken:从 Cookie 取ifaccessToken 为空 或者 过期{// 用 Cookie 里的 refresh 重新生成一个新的 accessnewAccessToken:用 refresh 生成新 token// 放行请求}翻译成人话就是如果请求头里没有 access_token或者它过期了后端不会直接拒绝而是扭头去看 Cookie 里有没有 refresh_token。有的话就自动帮你生成一个新的 access_token然后放行。这就是「自动签发兜底」。所以回到开头那个反直觉的现象你在 Postman 里没填请求头 token但 Postman 像浏览器一样自动把之前登录时存下的 Cookierefresh_token带上了后端发现请求头没 access就用 Cookie 里的 refresh 自动续了一个放行。所以「不带 token 也能通」是假象——不是没带是 refresh_token 躲在 Cookie 里偷偷兜底了。四、单 Token没有兜底必须带 token单 Token 的项目里只有一个 token没有 refresh_token 这层兜底。后端逻辑很简单请求头里有没有 token 有 → 验证放行 没有 → 直接 401拒绝没有 Cookie 里那层「备胎」所以调试工具请求头忘了带 token→ 直接 401拿不到数据必须手动把 token 放进请求头才能通。这就是双 Token 和单 Token 在调试时最大的体验差别。五、所以调试工具该怎么带 token分两种情况单 Token 项目或想标准地带上 access必须手动让调试工具在请求头里带 token。Apifox 里最简单的做法是「变量 引用」先发登录请求在「后置操作 → 提取变量」里用 JSONPath$.data.token把返回的 token 存成变量token这里的提取源选Response JSON 因为token是从后端接口的响应里提取的提取选JSONPath然后JSONPath里填你token在响应体中的位置比如我的后端返回的token在 data 里的token 里后续请求的请求头里加一行比如KeyValueaccess-token{{token}}发送时 Apifox 会自动把{{token}}换成真实 token。这样不用每次手动复制粘贴。这里的key是按你自己的后端逻辑来定的当然也可以是从Authorization取图片里的用法Bearer Token就是从Authorization里取的后面的value就是引用你第一步提取的环境变量也就是token。双 Token 项目虽然它「不带 access 也能通」靠 Cookie 里的 refresh 兜底但那是退化模式——每次请求都在偷偷续期、多查一次库。想标准一点还是建议按上面一样把 access_token 带上。结尾一句话总结双 Token 请求头没带 access 时Cookie 里的 refresh 会自动兜底续期所以「看起来不用带」单 Token 没有这层兜底请求头没带就是 401必须让调试工具带上。理解了这层「兜底」的差别再遇到「为什么这个项目不带 token 能通、那个不行」的困惑就能一眼看穿了。如果你也在学习后端开发欢迎来blog.tuoxie.asia一起交流。