JWT 调试小细节及Apifox使用小技巧
调接口时遇到一个有意思的现象：我的博客项目有完整的双Token机制，所以在调试工具（Apifox）里不做任何设置鉴权接口也能通；以前写的都是双Token项目，没怎么注意这件事，这几天写了个单 Token 的项目，调试没带 token 直接 401，研究了一通才搞明白——差别就在「双 Token 会自动兜底，单 Token 不会」。这篇正好讲讲这个，顺便说说调试工具怎么正确带 token。
双 Token 为什么「不带 token 也能通」？单 Token 就必须带
一、先记住一件事：token 是放在「请求头」里的
登录后，后端发给你一个 token，前端要把它存起来，以后每次请求时放进请求头里带给后端，后端验证通过才放行。
这是所有鉴权的基本玩法。不管是单 Token 还是双 Token，日常携带 token 的位置都是请求头。
二、双 Token：access 短效，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 像浏览器一样，自动把之前登录时存下的 Cookie（refresh_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 里后续请求的请求头里加一行，比如：
| Key | Value |
|---|---|
access-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一起交流。