前端通用 Token 全流程操作指南(常见常用版)

前端通用 Token 全流程操作指南(常见常用版)

本文梳理 所有前端框架通用 的 Token 操作逻辑,剥离具体项目/技术栈细节,聚焦「获取→存储→使用→过期→清除」的核心生命周期,每个步骤均标注「通用场景+通用方案+注意事项」,适合所有前端开发场景,可直接作为开发速查表。


前置说明:Token 的核心定位

Token 是后端签发的临时访问凭证,核心作用是:

  1. 证明“当前用户是谁”(身份认证);
  2. 证明“当前用户有权限访问”(权限校验)。

一、第一步:登录成功获取 Token

通用场景

用户通过账号密码/验证码/第三方登录等方式,向后端发起登录请求,后端验证通过后,在响应体中返回 Token。

通用方案

  1. 解析登录接口的响应数据;
  2. 根据后端接口文档,从响应体中提取 Token 字段(常见字段名:tokenaccess_tokendata.token);
  3. 获取到 Token 后,立即执行「存储」操作。

注意事项

  1. 必须以后端接口文档为准,不要硬猜字段名;
  2. 获取到 Token 后,不要只打印在控制台,必须立即存储;
  3. 若接口同时返回 refresh_token(刷新 Token),需一并存储。

二、第二步:存储 Token(核心是选对存储方式)

通用场景

将获取到的 Token 保存到前端,确保刷新页面后不丢失,且全局页面/组件都能读取

通用方案(三种常见存储方式对比)

存储方式特性适用场景通用代码示例(原生 JS)
localStorage永久存储(关闭浏览器/重启电脑不丢失),容量约 5MB,仅客户端可读。绝大多数 Web 应用(需求为“记住登录状态,下次打开不用重登”)。localStorage.setItem('token', '你的token值')
const token = localStorage.getItem('token')
sessionStorage会话存储(关闭标签页/浏览器后立即清空),容量约 5MB,仅客户端可读。安全性要求极高的应用(需求为“关闭浏览器就自动登出”,如银行、政务系统)。sessionStorage.setItem('token', '你的token值')
const token = sessionStorage.getItem('token')
Cookie可设置过期时间,容量约 4KB,支持自动携带在请求头中,服务端可读取。需服务端直接读取 Token 的场景,或有跨域/SSO(单点登录)需求的场景。document.cookie = 'token=你的token值; expires=过期时间; path=/'

注意事项

  1. 推荐优先选 localStorage:是目前最通用、最方便的存储方式;
  2. 不要同时用多种方式存储(如同时存 localStorage 和 Cookie),易导致数据不一致;
  3. 不要在 Token 中存储敏感信息(如密码、身份证号):Token 仅作为凭证,不承载业务数据。

三、第三步:请求接口时自动携带 Token

通用场景

每次向后端发起业务请求(如获取列表、提交数据)时,都需在请求头(Header) 中带上 Token,供后端验证身份。

通用方案

使用主流 HTTP 请求库的「请求拦截器」(如 Axios、Fetch 封装、umi-request),在请求发送前自动读取 Token 并添加到请求头,无需每次手动添加。

通用请求头格式(两种最常见)

自定义 token 头

token: <你的token值> 

标准 Authorization 头(推荐)

Authorization: Bearer <你的token值> 

注意事项

  1. 必须以后端接口文档为准,不要写错请求头字段名;
  2. 只有 Token 存在时才添加请求头,避免空 Token 导致接口报错;
  3. 不要在请求体(Body)中传递 Token(除非后端强制要求),请求头是标准做法。

四、第四步:处理 Token 过期

通用场景

Token 有有效期(常见为 2 小时/24 小时/7 天),过期后后端会拒绝请求并返回特定状态码(通常为 401 Unauthorized)。

通用方案

使用主流 HTTP 请求库的「响应拦截器」,统一处理 Token 过期逻辑:

  1. 判断响应状态码是否为 401(或后端约定的其他过期标识);
  2. 若确认过期:
    • 给用户友好提示(如“登录已过期,请重新登录”);
    • 清除所有存储的 Token(及用户信息);
    • 强制跳转到登录页。

注意事项

  1. 不要忽略 401 错误:Token 过期后用户无法继续操作,必须重新登录;
  2. 清除 Token 时要彻底:删除所有存储介质中的 Token(如同时删 localStorage 和全局状态);
  3. 跳转登录页时建议替换当前历史记录(避免用户点击“回退”回到过期页面)。

五、第五步:用户主动登出清除 Token

通用场景

用户点击“退出登录”按钮时,需清除所有登录相关数据,恢复到未登录状态。

通用方案

  1. 触发登出操作时,先给用户二次确认(如“确定要退出登录吗?”);
  2. 确认后执行清除操作:
    • 清除所有存储介质中的 Token(localStorage/sessionStorage/Cookie);
    • 清除全局状态中的用户信息(如头像、昵称);
  3. 强制跳转到登录页。

注意事项

  1. 不要省略二次确认:避免用户误触登出按钮;
  2. 登出后不要保留任何登录痕迹:确保下次打开应用是完全的未登录状态;
  3. 若后端有“登出接口”,建议先调用接口(通知后端销毁 Token),再执行前端清除操作。

六、第六步:路由/页面权限控制(进阶但常用)

通用场景

未登录的用户不能访问需要登录的页面(如首页、个人中心),已登录的用户不能访问登录页。

通用方案

使用路由守卫/权限拦截(如 Vue Router 的 beforeEach、React Router 的路由拦截),在页面跳转前统一校验:

  1. 定义「白名单」:不需要登录就能访问的页面(如登录页、注册页、404 页);
  2. 跳转前读取 Token,判断用户是否登录;
  3. 根据判断结果决定“放行”还是“跳转登录页”。

注意事项

  1. 不要忘记定义白名单:登录页本身不需要登录,否则会导致“无限重定向”;
  2. 权限控制仅做“前端拦截”:真正的权限校验必须在后端做(前端拦截防君子不防小人);
  3. 不要在权限拦截中做复杂的异步操作(如调接口验证 Token):会导致页面加载卡顿。

总结:Token 全流程核心逻辑

  1. 获取:登录接口返回 → 提取 Token;
  2. 存储:选对存储方式(推荐 localStorage)→ 全局可读取、刷新不丢;
  3. 使用:请求拦截器自动带 Token → 放在请求头里;
  4. 过期:响应拦截器处理 401 → 清除 Token、跳登录页;
  5. 清除:用户登出 → 彻底清除所有数据、跳登录页;
  6. 控制:路由守卫 → 未登录用户不能访问受保护页面。

避坑总览(新手必看)

  1. ❌ 不要只存全局状态不存本地存储:刷新页面后数据会清空;
  2. ❌ 不要在每个请求里手动加 Token:用请求拦截器统一处理;
  3. ❌ 不要忽略 Token 过期的 401 错误:必须强制用户重新登录;
  4. ❌ 不要在 Token 里存敏感信息:Token 仅作为凭证;
  5. ❌ 不要省略登出的二次确认:避免用户误操作。

Read more

Qwen-Image金融宣传案例:合规文案图像自动生成部署

Qwen-Image金融宣传案例:合规文案图像自动生成部署 1. 引言:金融宣传的合规挑战与AI机遇 金融行业的宣传物料,无论是线上广告、产品海报还是投资者教育图文,都面临一个核心难题:如何在确保内容合规、严谨的同时,又能高效、美观地完成视觉呈现?传统流程中,设计师需要反复与合规部门沟通,确保海报上的每一个字、每一个数字都准确无误,这不仅耗时耗力,还常常因为微小的文字调整而需要重新设计整个版面。 现在,有了Qwen-Image,这个痛点有了全新的解决方案。Qwen-Image是阿里云通义千问团队于2025年8月发布的图像生成基础模型,它最厉害的地方在于,能够精准地理解和渲染复杂的文本,尤其是包含多行、段落级中英文的文本。这意味着,你可以直接输入一段经过合规审核的、完整的金融文案,模型就能生成一张文字清晰、排版美观、与背景完美融合的高质量宣传图。 本文将带你一步步部署并使用Qwen-Image镜像,通过一个真实的“理财产品宣传海报”生成案例,展示如何将枯燥的合规文本,快速转变为专业、吸睛的视觉作品,真正实现金融宣传内容的“一键合规、秒级出图”。 2. Qwen-Image核

AI 监控我打游戏?Win11 Gaming Copilot 这波操作逆了天!附关闭教程 + 性能实测

AI 监控我打游戏?Win11 Gaming Copilot 这波操作逆了天!附关闭教程 + 性能实测

文章目录 * 一、玩家炸锅:我打游戏,微软 AI 在 “偷看”? * 二、更坑的是:AI 没帮上忙,游戏还变卡了! * 三、玩家怒了:微软近期操作,早把信任败光了! * 四、紧急避坑:手把手教你关了 “监控开关”! * 五、结语:AI 不是 “侵犯隐私” 的借口 作为一名常年泡在游戏里的玩家,最近 Win11 的操作直接给我整懵了 —— 微软刚推的 AI 游戏助手 Gaming Copilot,居然被曝默认在后台录屏、传数据?这可不是 “贴心辅助”,简直是 “隐形监控”!今天就扒一扒这事儿的来龙去脉,再教大家怎么关开关、避坑,文末还有性能实测数据,建议玩家收藏! 一、玩家炸锅:我打游戏,

ClawdBot真实案例:树莓派4上同时运行OCR/Whisper/vLLM,15用户并发无卡顿

ClawdBot真实案例:树莓派4上同时运行OCR/Whisper/vLLM,15用户并发无卡顿 1. 什么是ClawdBot?一个真正属于你的本地AI助手 ClawdBot不是另一个云端API包装器,也不是需要注册账号、绑定手机号的SaaS服务。它是一个你完全掌控的个人AI助手——所有计算发生在你自己的设备上,消息不上传、模型不调用第三方服务、对话历史默认不留存。你可以把它装在树莓派4里放在书桌角落,也可以部署在老旧笔记本上作为家庭AI中枢,甚至塞进一台闲置的NUC里变成办公室智能前台。 它的核心设计哲学很朴素:AI能力应该像电和水一样,成为你设备的底层能力,而不是需要反复登录的远程服务。当你在终端输入clawdbot devices list,看到的是真实连接到你本地机器的设备列表;当你执行clawdbot models list,列出的是正在你内存中运行的vLLM实例;当你在Telegram里发一条语音,转写、翻译、响应全过程都在你家里的树莓派上完成——没有数据离开你的局域网。 这种“本地即服务”的模式,带来三个实实在在的好处:一是隐私可控,聊天内容、图片、语音全部留在