前言

本文梳理 所有前端框架通用 的 Token 操作邏輯，剝離具體項目/技術棧細節(jié)，聚焦「獲取→存儲→使用→過期→清除」的核心生命周期，每個步驟均標注「通用場景+通用方案+注意事項」，適合所有前端開發(fā)場景，可直接作為開發(fā)速查表。

前置說明：Token 的核心定位

Token 是后端簽發(fā)的臨時訪問憑證，核心作用是：

1. 證明“當前用戶是誰”（身份認證）；
2. 證明“當前用戶有權限訪問”（權限校驗）。

一、第一步：登錄成功獲取 Token

通用場景

用戶通過賬號密碼/驗證碼/第三方登錄等方式，向后端發(fā)起登錄請求，后端驗證通過后，在響應體中返回 Token。

通用方案

1. 解析登錄接口的響應數(shù)據(jù)；
2. 根據(jù)后端接口文檔，從響應體中提取 Token 字段（常見字段名：token、access_token、data.token）；
3. 獲取到 Token 后，立即執(zhí)行「存儲」操作。

注意事項

1. 必須以后端接口文檔為準，不要硬猜字段名；
2. 獲取到 Token 后，不要只打印在控制臺，必須立即存儲；
3. 若接口同時返回 refresh_token（刷新 Token），需一并存儲。

二、第二步：存儲 Token（核心是選對存儲方式）

通用場景

將獲取到的 Token 保存到前端，確保刷新頁面后不丟失，且全局頁面/組件都能讀取。

通用方案（三種常見存儲方式對比）

注意事項

1. 推薦優(yōu)先選 localStorage：是目前最通用、最方便的存儲方式；
2. 不要同時用多種方式存儲（如同時存 localStorage 和 Cookie），易導致數(shù)據(jù)不一致；
3. 不要在 Token 中存儲敏感信息（如密碼、身份證號）：Token 僅作為憑證，不承載業(yè)務數(shù)據(jù)。

三、第三步：請求接口時自動攜帶 Token

通用場景

每次向后端發(fā)起業(yè)務請求（如獲取列表、提交數(shù)據(jù)）時，都需在請求頭（Header） 中帶上 Token，供后端驗證身份。

通用方案

使用主流 HTTP 請求庫的「請求攔截器」（如 Axios、Fetch 封裝、umi-request），在請求發(fā)送前自動讀取 Token 并添加到請求頭，無需每次手動添加。

通用請求頭格式（兩種最常見）

1. 標準 Authorization 頭（推薦）：

   Authorization: Bearer <你的token值>

2. 自定義 token 頭：

   token: <你的token值>

注意事項

1. 必須以后端接口文檔為準，不要寫錯請求頭字段名；
2. 只有 Token 存在時才添加請求頭，避免空 Token 導致接口報錯；
3. 不要在請求體（Body）中傳遞 Token（除非后端強制要求），請求頭是標準做法。

四、第四步：處理 Token 過期

通用場景

Token 有有效期（常見為 2 小時/24 小時/7 天），過期后后端會拒絕請求并返回特定狀態(tài)碼（通常為 401 Unauthorized）。

通用方案

使用主流 HTTP 請求庫的「響應攔截器」，統(tǒng)一處理 Token 過期邏輯：

1. 判斷響應狀態(tài)碼是否為 401（或后端約定的其他過期標識）；
2. 若確認過期：
   • 給用戶友好提示（如“登錄已過期，請重新登錄”）；
   • 清除所有存儲的 Token（及用戶信息）；
   • 強制跳轉到登錄頁。

注意事項

1. 不要忽略 401 錯誤：Token 過期后用戶無法繼續(xù)操作，必須重新登錄；
2. 清除 Token 時要徹底：刪除所有存儲介質中的 Token（如同時刪 localStorage 和全局狀態(tài)）；
3. 跳轉登錄頁時建議替換當前歷史記錄（避免用戶點擊“回退”回到過期頁面）。

五、第五步：用戶主動登出清除 Token

通用場景

用戶點擊“退出登錄”按鈕時，需清除所有登錄相關數(shù)據(jù)，恢復到未登錄狀態(tài)。

通用方案

1. 觸發(fā)登出操作時，先給用戶二次確認（如“確定要退出登錄嗎？”）；
2. 確認后執(zhí)行清除操作：
   • 清除所有存儲介質中的 Token（localStorage/sessionStorage/Cookie）；
   • 清除全局狀態(tài)中的用戶信息（如頭像、昵稱）；
3. 強制跳轉到登錄頁。

注意事項

1. 不要省略二次確認：避免用戶誤觸登出按鈕；
2. 登出后不要保留任何登錄痕跡：確保下次打開應用是完全的未登錄狀態(tài)；
3. 若后端有“登出接口”，建議先調(diào)用接口（通知后端銷毀 Token），再執(zhí)行前端清除操作。

六、第六步：路由/頁面權限控制（進階但常用）

通用場景

未登錄的用戶不能訪問需要登錄的頁面（如首頁、個人中心），已登錄的用戶不能訪問登錄頁。

通用方案

使用路由守衛(wèi)/權限攔截（如 Vue Router 的 beforeEach、React Router 的路由攔截），在頁面跳轉前統(tǒng)一校驗：

1. 定義「白名單」：不需要登錄就能訪問的頁面（如登錄頁、注冊頁、404 頁）；
2. 跳轉前讀取 Token，判斷用戶是否登錄；
3. 根據(jù)判斷結果決定“放行”還是“跳轉登錄頁”。

注意事項

1. 不要忘記定義白名單：登錄頁本身不需要登錄，否則會導致“無限重定向”；
2. 權限控制僅做“前端攔截”：真正的權限校驗必須在后端做（前端攔截防君子不防小人）；
3. 不要在權限攔截中做復雜的異步操作（如調(diào)接口驗證 Token）：會導致頁面加載卡頓。

總結：Token 全流程核心邏輯

1. 獲取：登錄接口返回 → 提取 Token；
2. 存儲：選對存儲方式（推薦 localStorage）→ 全局可讀取、刷新不丟；
3. 使用：請求攔截器自動帶 Token → 放在請求頭里；
4. 過期：響應攔截器處理 401 → 清除 Token、跳登錄頁；
5. 清除：用戶登出 → 徹底清除所有數(shù)據(jù)、跳登錄頁；
6. 控制：路由守衛(wèi) → 未登錄用戶不能訪問受保護頁面。

避坑總覽（新手必看）

1. ? 不要只存全局狀態(tài)不存本地存儲：刷新頁面后數(shù)據(jù)會清空；
2. ? 不要在每個請求里手動加 Token：用請求攔截器統(tǒng)一處理；
3. ? 不要忽略 Token 過期的 401 錯誤：必須強制用戶重新登錄；
4. ? 不要在 Token 里存敏感信息：Token 僅作為憑證；
5. ? 不要省略登出的二次確認：避免用戶誤操作。

總結 

到此這篇關于前端通用Token操作的文章就介紹到這了,更多相關前端通用Token操作內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論