前端通用 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

GHCTF2025-WEB题解:如何用SSTI绕过WAF黑名单(附实战payload)

从GHCTF2025实战出发:深度拆解SSTI黑名单绕过策略与高阶Payload构造 最近在GHCTF2025的WEB赛道上,一道看似简单的文件上传题目,却让不少选手陷入了“知道有洞,但payload总被拦截”的困境。这道题表面上是文件上传,实际上却是一场针对SSTI(服务器端模板注入)绕过能力的深度考验。我在实际测试中发现,很多选手能够快速识别出SSTI漏洞的存在,但在面对严格的黑名单过滤时,却往往束手无策,反复尝试的payload都被WAF无情拦截。 这种情况在真实的渗透测试和CTF比赛中并不少见。WAF(Web应用防火墙)的过滤规则越来越智能,传统的{ {7*7}}测试虽然能确认漏洞,但真正要执行命令、读取文件时,那些包含os、flag、__builtins__等关键词的payload几乎都会被第一时间拦截。这道题的精妙之处在于,它模拟了一个相对真实的防御环境——不仅过滤常见敏感词,还对下划线这种在Python反射中至关重要的字符进行了拦截。 本文将从实战角度出发,不局限于GHCTF2025这一道题目,而是系统性地探讨SSTI黑名单绕过的核心思路、技术原理和进阶技巧。我会结

前端图片加载失败、 img 出现裂图的原因全解析

在前端开发过程中,我们几乎都遇到过这种情况: 页面中某张图片加载不出来,显示成一个小小的“裂图”图标。 这看似简单的问题,实际上可能由多种原因造成,尤其是在 HTTPS 环境下,混合内容机制(Mixed Content) 是最常见、也最容易被误解的根源之一。 本文将带你系统梳理裂图的各种原因、排查思路,并重点讲清楚混合内容的原理与浏览器行为。 一、什么是“裂图”? “裂图”(broken image)是指浏览器尝试加载 <img> 标签的图片资源失败时的表现形式。 常见表现: * 图片区域显示为灰底、叉号、占位符; * 控制台出现 Failed to load resource 或 Mixed Content 警告; * Network 面板中图片请求状态码为 404 / 403 / blocked。 二、常见的裂图原因汇总

WebRTC / HLS / HTTP-FLV 的本质区别与选型指南

WebRTC / HLS / HTTP-FLV 的本质区别与选型指南

在做系统级直播(而不是自己本地播放)时,很多人都会遇到一个经典问题: WebRTC、HLS、HTTP-FLV 到底有什么区别? 项目中到底该选哪个? 传输协议不同 → 延迟不同 → 兼容性 / 稳定性 / 成本不同 在系统里选哪个,核心看两点: 你要多低的延迟?你要多强的兼容和稳定? 一、简介 * WebRTC:超低延迟(0.2 ~ 1s),适合实时监控、无人机、实时指挥 * HLS(hls.js):最稳、最通用(5 ~ 15s),适合活动直播、课程、公开大并发 * HTTP-FLV(flv.js):中低延迟(1 ~ 3s),适合想比 HLS 低延迟,但不想用 WebRTC 的场景(

SDWebImage 在 Flutter 中的使用:通过插件桥接

SDWebImage 在 Flutter 中的使用:通过插件桥接 关键词:SDWebImage、Flutter插件、跨平台桥接、MethodChannel、图片加载缓存 摘要:本文将带你探索如何在 Flutter 中通过插件桥接技术调用 iOS 原生的 SDWebImage 库。我们会从背景需求出发,用“跨国快递”的比喻解释桥接原理,逐步拆解核心概念,结合代码实战演示如何实现图片加载与缓存,并总结常见问题与未来优化方向。即使你是 Flutter 新手,也能轻松理解跨平台桥接的底层逻辑! 背景介绍 目的和范围 在 Flutter 开发中,图片加载是高频需求。虽然 Flutter 自带 cached_network_image 等第三方库,但在 iOS 平台上,原生的 SDWebImage 经过多年优化,在缓存策略、