文章目录引言HTTP 是无状态的服务器怎么知道「你是谁」zustand用一个「仓库」管好全局登录状态为什么需要状态管理建一个用户 store在组件里怎么用mockjs大前端自己搭一套鉴权后端axios 的 baseURL 约定vite 的 mockjs 插件mock 接口长什么样JSONWebTokensign 和 verify 这对「锁」与「钥匙」JWT 的两个核心动作为什么 JWT 能解决 cookie/session 的分布式难题JWT 的结构顺带看懂那串 token拦截器axios 在背后默默做的那些事完整拦截器代码逐个拆解项目里完整的 API 封装全文总结核心知识点复盘常见问题 / 避坑指南引言HTTP 是无状态的服务器怎么知道「你是谁」要理解 JWT得先从 HTTP 的一个根本特性说起HTTP 是无状态Stateless的。什么叫无状态就是服务器「不长记性」。你第一次请求登录服务器处理完就忘了你你第二次再来请求一个受保护的数据服务器一脸茫然——「你是谁凭什么给你」但现实里绝大多数应用都需要「记住用户」。比如你登录了淘宝刷新页面之后还是登录状态不需要每次重新输密码。这个「记住你是谁」的机制就是鉴权Authentication也就是我们常说的「登录态保持」。JWTJSON Web Token就是解决这个问题的一套方案。它的核心思路用一句话概括登录时服务器把「用户是谁」的信息打包成一串加密的凭证token发给客户端之后客户端每次请求都把这串凭证带上服务器一看凭证就知道「哦是你」。这个凭证放在哪里呢放在 HTTP 请求的Authorization请求头里格式是Authorization: Bearer tokenBearer是「持有者」的意思表示「持有这个 token 的人就是被授权的人」。那么登录的完整流程是这样的1. 用户在 /login 页面输入 admin / 123456 2. 前端 POST 到后端 /login 接口 3. 后端校验用户名密码正确的话 把用户身份 JSON 对象 { id, name, role } 用密钥签名成一个 JWT token单向加密操作 返回 token 给前端 4. 前端把 token 存到 localStorage 5. 之后每次请求前端自动在 Authorization 头里带上 token 6. 后端从 Authorization 头取出 token用同一把密钥解密verify 还原出 JSON 身份对象确认「这是合法用户」用一张流程图表示就是服务器(后端)浏览器(前端)服务器(后端)浏览器(前端)POST /login (admin/123456)校验密码 sign(用户JSON) 生成 token返回 { code:0, token, user }把 token 存进 localStorageGET /api/repo Authorization: Bearer tokenverify(token) 还原出用户身份返回受保护的数据理解了这个整体流程我们再用一个真实可跑的项目React Vite zustand mockjs axios一步步把它落地。zustand用一个「仓库」管好全局登录状态为什么需要状态管理先想一个问题登录成功后这个「已经登录了」的状态要存在哪里才能让整个应用都能用到比如下面这些地方都要用「登录状态」顶部导航栏Nav登录了才显示「Logout」按钮没登录显示「Login」。路由守卫RequireAuth没登录访问/pay要跳回登录页。登录页Login登录成功后要把 token 写进去。这些组件分布在不同的路由、不同的层级里。如果只用 React 最基础的父子传值props那状态就得一层层往下传如果两个组件离得很远还得层层往上提代码会变得很啰嗦这就是常说的「props 地狱」。React 官方给了另一个方案createContext useContext可以跨层级共享状态。它的思路是「把状态放到一个 Context 容器里谁用谁从容器里取」。这能解决问题但写起来样板代码多而且一旦状态变多、更新频繁性能也要小心Context 的值一变所有用它的组件都会重渲染。所以这里引入一个更轻量、更省事的状态管理库zustand。zustand 是一个极轻量的状态管理库核心思想就是「一个 store仓库 一套读写方法」。它不依赖 Context不要求你包一层 Provider上手极快。用一句话记住它React App UI 组件Component 状态仓库StoreUI 负责「长什么样」Store 负责「数据是什么、怎么改」。建一个用户 store项目里的 store/user.js 就是这样一个仓库// store/user.js// 全局负责提供「用户身份状态」的存储import{create}fromzustandexportconstuseAuthStorecreate(set({// 状态token 从 localStorage 读取保证刷新页面后登录态不丢token:localStorage.getItem(token)||,// 状态user 是 JSON 字符串读出来要转回对象user:JSON.parse(localStorage.getItem(user))||null,// action登录成功后调用把 token 和 user 存起来setAuth:({token,user}){// 1. 持久化到 localStorage刷新不丢localStorage.setItem(token,token)localStorage.setItem(user,JSON.stringify(user))// 2. 更新内存中的状态触发用到它的组件重新渲染set({token,user})},// action退出登录清空状态logout:(){localStorage.removeItem(token)localStorage.removeItem(user)set({token:,user:null})},}))这段代码有几个关键点拆开讲create(set ...)zustand 的入口set是修改状态的方法。状态和动作放在一起token、user是状态数据setAuth、logout是动作改数据的方法。为什么要同时写 localStorage 和内存状态内存状态set({...})负责「立即让界面响应」localStorage 负责「刷新页面后还在」。因为 React 的内存状态一刷新就没了而 localStorage 存在浏览器里关掉页面都还在。在组件里怎么用用起来非常直接一行就能拿到状态或动作// 拿到 token只订阅这一个字段其他字段变化不会影响这个组件consttokenuseAuthStore(statestate.token)// 拿到修改状态的方法constsetAuthuseAuthStore(statestate.setAuth)登录页里这样写Login.jsx核心片段constsetAuthuseAuthStore(statestate.setAuth)consthandleLoginasynce{e.preventDefault()constresawaitlogin(formData)// 调后端登录接口if(res.code0){setAuth({token:res.token,user:res.user})// 存进全局 storenavigate(from,{replace:true})// 跳转到登录前想去的页面}else{alert(res.message||登录失败)}}导航栏里这样用Nav.jsxconsttokenuseAuthStore(statestate.token)constuseruseAuthStore(statestate.user)constlogoutuseAuthStore(statestate.logout)// 有 token 才显示 Logout 按钮有 user 才显示用户名{!tokenLink to/loginLogin/Link}{usera${user.username}/a}{tokenbutton onClick{logout}Logout/button}路由守卫里这样用RequireAuth.jsximport{Navigate}fromreact-router-domimport{useAuthStore}from../store/userfunctionRequireAuth({children}){consttokenuseAuthStore(statestate.token)// 没登录重定向到登录页if(!token){returnNavigate to/loginreplace/}// 登录了正常渲染受保护的内容returndiv{children}/div}可以看到不管是哪个组件、隔着多少层路由只要用useAuthStore就能共享同一份登录状态这就是全局状态管理带来的便利。mockjs大前端自己搭一套鉴权后端前端开发时后端接口往往还没就绪。这时候「mock」就派上用场了——用一个假的后端模拟真实接口的返回让前端能独立跑起来联调。axios 的 baseURL 约定项目里所有请求都走 axios 实例api/config.js其中第一件事就是配置baseURLconstinstanceaxios.create({baseURL:/api,// 所有请求自动拼上 /api 前缀timeout:5000,})这样业务代码里写axios.get(/repo)实际请求的地址就是/api/repo。vite 的 mockjs 插件mock 是通过vite-plugin-mock插件接入的配置在vite.config.jsimport{defineConfig}fromviteimportreactfromvitejs/plugin-reactimport{viteMockServe}fromvite-plugin-mockexportdefaultdefineConfig({plugins:[react(),viteMockServe({mockPath:mock,// mock 文件的目录enable:true,// 开启 mock}),],})mockPath: mock表示把项目根目录下的mock/文件夹里的接口定义都挂载到 dev server 上。于是/api/login、/api/repo这些地址dev server 会直接用 mock 数据响应不用真实后端。mock 接口长什么样看mock/user.jsimportjwtfromjsonwebtokenconst{sign}jwtconstsecretsecret819!$// 签名的密钥实际项目要更复杂并保密exportdefault[{url:/api/login,method:POST,timeout:2000,response:(req){constbodyreq.body// 校验用户名密码if(body.username!admin||body.password!123456){return{code:-1,message:用户名或密码错误}}// 密码正确把用户身份打包成 JWT 发出去consttokensign({user:body.username,role:admin},// 要加密的身份信息secret,// 密钥{expiresIn:86400},// 有效期 24 小时)return{code:0,user:{username:body.username},token,}},},{url:/api/repo,method:GET,response:(req){// 从请求头取出 token前面要防御没有 header 会报错constauthorizationreq.headers[authorization]if(!authorization){return{code:401,msg:缺少 token}}consttokenauthorization.split( )[1]// Bearer xxx 取后半段try{constdecodedjwt.verify(token,secret)// 验签还原身份return{code:0,data:decoded.user}}catch(e){return{code:401,msg:token 验证失败}}},},]这里就能看到一整套鉴权的两端/api/login负责签发sign把用户身份变成 token/api/repo负责验证verify把 token 还原成用户身份。sign和verify就是 JWT 最核心的两个动作下面单独展开讲。JSONWebTokensign 和 verify 这对「锁」与「钥匙」JWT 的两个核心动作JWT 的整个生命周期就围绕两个动作展开sign签名/签发把「用户身份 JSON 对象」用密钥加密生成一串 token。verify验签/验证拿到 token用同一把密钥解密还原出「用户身份 JSON 对象」。可以打个比方sign就像「把纸条放进一个带锁的信封锁好」verify就像「用钥匙开锁取出纸条」。锁和钥匙是同一把密钥对称加密所以任何一台持有这把密钥的服务器都能打开这封信——这一点至关重要直接决定了 JWT 的分布式优势。为什么 JWT 能解决 cookie/session 的分布式难题传统的登录方案是cookie session用户登录后服务器在自己的内存里存一份 session 会话对象比如sessionId → { userId, role }。服务器把sessionId写进 cookie 返回给浏览器。之后浏览器每次请求自动带上 cookie 里的sessionId。服务器拿到sessionId去内存里查对应的 session 对象就知道用户是谁。这个方案单机跑得很好但一旦服务变多分布式/集群就出问题假设有 A、B 两台服务器。用户第一次登录连到了 Asession 存在 A 的内存里。第二次请求负载均衡把它分发到了 B。B 的内存里没有这个 sessionId 对应的会话对象。于是 B 一脸茫然「我不认识这个 sessionId」用户就被当成未登录了。要解决就得把 session 抽出来放到一个共享的地方比如 Redis这又增加了架构复杂度和成本。JWT 就没有这个问题。因为 token 里自己就包含了身份信息不依赖服务器内存用户登录连到 AA 用密钥 sign 出 token 发给用户。用户下次请求连到 BB 用同一把密钥verify 这个 token直接还原出身份对象。任何一台持有同一把密钥的服务器都能独立完成验签不需要去「别人家」查 session。这就是 JWT 天然适合分布式、微服务的原因。JWT 的结构顺带看懂那串 token一个真实的 JWT token 长这样用.分成三段eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ.xxxxx |------- Header -------|----------- Payload ------------|-- Signature --|Header说明「签名用了什么算法」比如 HS256。Payload真正装身份信息的部分就是 sign 时传入的那个 JSON 对象。注意它只是Base64 编码不是加密——任何人拿到都能解开看内容所以绝不能在 payload 里放密码等敏感信息。Signature用「Header Payload 密钥」算出来的一段签名用来防篡改。重要认知JWT 的作用不是「保密」而是「防篡改 证明身份」。payload 里的内容是公开可读的但签名保证了「只要内容被人改过一个字验签就会失败」。拦截器axios 在背后默默做的那些事前端最繁琐的一件事就是每次请求都要手动带上 token。如果每个接口都手写一遍headers: { Authorization: ... }既容易漏又难维护。axios 的拦截器interceptors就是为了解决「每个请求都做同一件事」而生的。它能在请求发出去之前和响应回来之后统一做一层处理。完整拦截器代码项目里的api/config.js是核心importaxiosfromaxiosconstinstanceaxios.create({baseURL:/api,timeout:5000,})// —— 请求拦截器每个请求发出去前统一干这件事 ——instance.interceptors.request.use(config{// 从 localStorage 取出登录时存的 tokenconsttokenlocalStorage.getItem(token)// 如果有 token就自动加到请求头里后端才能验签if(token){config.headers[authorization]Bearer${token}}// 一定要把改好的 config 返回去请求才会继续发returnconfig})// —— 响应拦截器每个响应回来后统一干这件事 ——instance.interceptors.response.use(res{// 直接返回 res.data这样业务代码里拿到的就是后端真正返回的数据returnres.data})exportdefaultinstance逐个拆解1. 请求拦截器做了什么它拦截的是「发请求前的那一刻」。在这里它做的事是从localStorage读 token如果有就往config.headers[authorization]塞Bearer token必须return config——这是最容易踩的坑忘了 return请求就发不出去了。有了它业务代码里写axios.get(/repo)就够了token 会自动带上这就是开头流程图里「每次请求自动带 token」的实现。2. 响应拦截器做了什么它拦截的是「响应回来的那一刻」。它把res剥掉一层直接返回res.data。为什么这么做因为 axios 默认返回的res结构是{data:{code:0,data:{...},token:...},// 后端真正返回的数据status:200,// HTTP 状态码headers:{...},// 响应头config:{...},// 请求配置}业务代码真正关心的只有data这一层。所以在响应拦截器里直接return res.data业务代码里const res await login(...)拿到的就直接是{ code, token, user }少写一层res.data.data代码更清爽。这也解释了为什么登录代码里能直接写res.code 0、res.token、res.user——因为响应拦截器已经帮你把外面那层壳剥掉了。项目里完整的 API 封装基于上面这套拦截器业务 API 就非常简洁了api/user.js和api/repo.js// api/user.jsimportaxiosfrom./configexportconstloginasync(data){constresawaitaxios.post(/login,data)returnres}// api/repo.jsimportaxiosfrom./configexportconstgetRepoasync(){constresawaitaxios.get(/repo)// 请求头会自动带上 tokenreturnres}全文总结这篇文章用一个可运行的小项目把 JWT 登录鉴权的完整链路串了一遍HTTP 无状态是问题的起点JWT 用「服务器签发 token、客户端每次带上、服务器验签」的方式解决「记住用户」。zustand负责把「登录状态 用户信息」变成全局可共享的数据跨路由、跨组件统一管理。mockjs vite-plugin-mock让前端在没有真实后端时也能模拟出一套带鉴权的接口。JWT 的 sign/verify是鉴权的核心且因为 token 自带身份信息天然适合分布式比 cookie/session 更有优势。axios 拦截器把「自动带 token」和「统一剥壳返回」这两件重复劳动集中处理业务代码因此保持简洁。核心知识点复盘概念一句话解释关键点无状态服务器不记住你每次请求都是新的所以需要 token 来「自证身份」Bearer token放在Authorization头里的凭证格式Bearer tokensign把身份 JSON 用密钥加密成 token只做一次在登录时verify把 token 用同一把密钥还原成身份每个受保护请求都要做zustand store全局共享的状态仓库状态 动作放一起localStorage浏览器持久化存储存 token刷新不丢baseURL请求地址统一前缀/api请求拦截器发请求前统一处理自动加 token必须 return config响应拦截器响应回来后统一处理剥壳返回 res.data一句话串起整个流程登录 → 后端sign生成 token → 前端存进 localStorage 和 zustand → 之后每次请求由 axios 请求拦截器自动带上Bearer token→ 后端verify还原身份 → 返回数据响应拦截器剥壳后交给业务代码。常见问题 / 避坑指南1. token 为什么要存 localStorage而不是存内存变量因为刷新页面后React 内存里的状态会全部清空。如果 token 只存在内存刷新一次就「被登出」了。存 localStorage 才能让登录态在刷新后保留。zustand store 里那句token: localStorage.getItem(token) || 就是干这个的——初始化时先从 localStorage 读回来。2. 请求拦截器里忘了return config会怎样请求会发不出去而且往往没有任何报错提示非常难排查。拦截器里改完 config 后一定要return config。3. JWT 的 payload 能放密码吗绝对不能。payload 只是 Base64 编码任何人都能解码看到内容它不加密。所以密码、身份证号等敏感信息绝不能放进 token。token 的作用是「防篡改、证明身份」不是「保密」。4. 为什么后端取 token 时要authorization.split( )[1]因为请求头的值是Bearer eyJhbGci...这种「前缀 空格 token」的格式。split( )[1]就是按空格切开取第 2 段真正的 token。5. mock 接口里最容易崩的坑不判空就直接req.headers[authorization].split(...)。如果请求没带Authorization头比如未登录时访问了受保护接口req.headers[authorization]是undefined直接.split()会抛TypeError严重时甚至能把 dev server 整个搞崩。取头之前一定要先判空没有就返回 401。6. JWT 过期了怎么办token 里有expiresIn有效期。过期后后端verify会失败返回 401。生产环境常见的做法是前端收到 401 就清空 token 并跳登录页或用 refresh token 静默续期。这也是为什么「响应拦截器」很关键——可以在那里统一拦截 401 做登出处理。7. 前后端分离时mock 和真实后端的地址怎么切换靠baseURL。mock 阶段baseURL: /api走 vite 的 mock联调真实后端时改成后端实际地址比如http://localhost:8080即可业务代码一行都不用动。