无感刷新 Token 本质是前端 JavaScript 配合后端接口协作完成的，HTML 仅承载逻辑；因其静态性无法发起请求、处理响应或控制鉴权头，故不能单独实现无感刷新。
无感刷新 Token 本质不是 HTML 能独立完成的事，而是前端 JavaScript 配合后端接口协作的结果；HTML 本身没有刷新 Token 的能力，它只负责承载和触发逻辑。
为什么不能只靠 HTML 实现无感刷新 Token
HTML 是静态标记语言，不执行逻辑、不发起请求、不处理响应。所谓“无感”，指的是用户未主动操作（如点击登录）时，前端自动检测 Token 过期并静默续期——这必须依赖 JavaScript 的定时检查、请求拦截、响应拦截等能力。
常见误解是把 <meta http-equiv="refresh"> 当作“无感刷新”，但它会强制重载整个页面，不仅不无感，反而打断用户操作，且无法携带鉴权头或处理 401 响应。
-
<meta http-equiv="refresh" content="1800;url=/login">是被动跳转，非无感 - Token 刷新需携带
refresh_token发起 POST 请求，HTML 表单无法在后台静默完成 - 刷新后的新
access_token需更新到请求头（如Authorization: Bearer xxx），HTML 无运行时控制权
实际可行的无感刷新方案（基于 JavaScript + Axios）
主流做法是在请求拦截器中统一处理 401，捕获后不暴露错误，而是用缓存的 refresh_token 向 /auth/refresh 发起续期请求；成功后再重放原请求。
立即学习“前端免费学习笔记（深入）”；
关键点在于：避免并发刷新（多个 401 同时触发多次刷新请求）、保证刷新期间请求排队、防止重复写入新 Token。
- 用一个
isRefreshing标志位 +failedQueue数组暂存待重发请求 - 刷新成功后遍历
failedQueue并 resolve 每个请求的 Promise - 刷新失败则清空队列，跳转登录页（
window.location.href = '/login'） - Axios 的
interceptors.response.use和interceptors.request.use是核心钩子
容易被忽略的三个坑
很多实现跑通了但上线后出问题，往往卡在这几个细节上：
- 后端返回的新
access_token有效期没校验，前端直接覆盖本地存储，导致下次请求仍过期 -
refresh_token本身也过期或被撤回，但前端未判断响应状态码（如 403），陷入无限刷新循环 - 跨 Tab 场景下，一个 Tab 刷新了 Token，其他 Tab 还在用旧 token，结果并发触发多次刷新——需要借助
localStorage+storage事件同步状态
真正可靠的无感刷新，90% 的工作量不在“怎么发请求”，而在“怎么协调状态、排队、降级和兜底”。别省略失败回调和日志埋点，否则线上出了问题，连哪一步断掉都看不到。
