在 B站 AI 創造公開賽 上“70億 token做了個 AI 德國軍官監督我學習”是一個很容易被點開的項目它把大模型從被動的問答工具變成了一個會施壓、會監督、會反饋的學習伙伴。但從開發者視角看這個標題更值得注意的不是“德國軍官”而是“70億 token”和“AI 監督”背后的工程成本與登錄體驗問題。這類項目表面上是一個創意 demo實際落地時會遇到三個非常具體的工程問題大模型 token 消耗怎么估算和控制AI 角色如何在多輪對話里保持穩定用戶登錄狀態如何在長期使用中不頻繁中斷。熱搜詞里大量出現的 token 失效、token exchange failed、JWT 續簽都和這些問題直接相關。下面從工程角度把這個項目拆開重點講清楚 token 相關的成本模型、登錄報錯排查和續簽設計。1. 先拆解“AI 德國軍官監督學習”這類項目的真正難點1.1 表面是創意本質是完整的人機交互閉環“AI 德國軍官監督我學習”不是一個單純的聊天機器人。用戶打開頁面后看到的不是一個溫柔的回答框而是一個有固定性格、會定時提醒、會檢查進度、會用嚴肅語氣反饋的角色。要實現這個效果至少需要四條鏈路交互入口用戶輸入文字或者通過語音與 AI 對話。角色引擎大模型按設定好的軍官人格、語氣、規則生成回復。任務狀態系統需要知道用戶當前學什么、學到哪里、距離截止時間還有多久。反饋閉環用戶提交學習成果后AI 判斷是否達標并輸出夸獎、批評或新的任務安排。用一張表描述模塊。模塊承擔職責常見落地技術角色設定固定“德國軍官”的人設、語氣、行為邊界system prompt 提示詞模板對話交互接收用戶輸入并生成回復大模型 Chat Completions API語音能力把 AI 回復變成語音或把用戶語音轉成文字TTS / ASR任務管理記錄學習目標、起止時間、完成狀態Redis / MySQL / KV 存儲監督觸發定時提醒、超時警告、進度檢查定時任務 消息推送這些模塊共同構成一個“AI Agent”而不是“AI 客服”。用戶在頁面上看到的是一段自然對話但背后每一次消息都要經過狀態查詢、提示詞組裝、模型調用、結果校驗和記錄存儲。1.2 三個躲不開的工程問題角色、成本、登錄態實際開發中最容易讓項目卡住的不是“大模型能不能生成軍官語氣”而是下面三個問題。第一個是角色穩定性。“德國軍官”的設定寫在 system prompt 里但多輪對話之后模型可能忘記規則語氣越來越隨意。這個問題不能靠繼續堆提示詞解決而是要在會話構建時把關鍵規則固定在最前面并用結構化輸出約束模型的判斷結果。第二個是成本與性能。每一個監督互動都需要攜帶角色設定、近期對話歷史、當前任務狀態。調用次數一多token 消耗就變成一筆必須面對的成本。標題里的“70億 token”放在工程語境里就是整個系統累計消耗的 token 數量級。第三個是登錄態。如果這個項目只在自己電腦上演示登錄可以不考慮。但只要部署到公網多人使用或者需要把學習記錄長期保存在服務器就必須有用戶體系。用戶體系一旦引入token 失效、過期、刷新、退出登錄就會成為頻繁出現的故障點。這三個問題對應了后面的內容先看 token 成本和角色設定再看認證 token 的報錯和續簽最后落到上線檢查清單。1.3 哪些讀者會從中拿到實際收益以下幾個場景比較典型正在寫 AI Agent 項目但不知道如何估算大模型 token 消耗。在接入第三方登錄或 AI 服務時撞到 token exchange failed不知道從哪查起。被 401、403、refresh token 過期反復打斷想設計一個完整的登錄續簽方案。想把“AI 監督學習”“AI 虛擬角色”這類創意做成可上線、可長期服務用戶的產品。如果你的目標只是跑通一個 Demo可以直接復制提示詞如果想讓它穩定地跑一個學期就必須把后面的工程問題補齊。2. “70億 token”到底指的是什么AI 應用的算力成本模型2.1 認證 token 和大模型 token 是兩回事在討論報錯之前先做一個概念區分。開發 AI 項目時“token”這個詞會出現兩次。第一次出現在用戶登錄系統里access token、refresh token 是訪問憑據作用是告訴服務器“當前請求來自哪個用戶”。第二次出現在大模型調用里模型會把文本切成一個個 token 來理解上下文。token 是文本長度和計算量的基本單位。熱搜詞里大量出現“token失效”“JWT實現token續簽”“cookie session token區別”這些屬于用戶登錄鏈路而標題里的“70億 token”更接近大模型調用量。兩個 token 名字相同但職責完全不同排查問題時如果混在一起很容易走彎路。2.2 70 億 token 消耗的估算思路在 LLM 應用中一次對話請求的 token 消耗不能只看用戶輸入的一句話。以監督學習場景為例一次發給模型的請求通常由四部分組成系統指令軍官人格、行為規則、監督流程可能占 800 到 1500 token。歷史消息之前幾輪對話內容尤其當上下文窗口很長時歷史會占據大頭。用戶當前消息文字可能很短語音轉文字后可能更長。模型輸出AI 軍官評分、催促、布置任務一般幾百到上千 token。粗略估算可以這樣算單次請求 token 約等于“系統指令 歷史消息 當前用戶消息 模型輸出 工具返回內容”。假設平均每次監督互動消耗 6000 token那么 70億 token 大約對應 116 萬次請求。如果平均請求更長比如 20000 token則只有 35 萬次。這個換算關系說明70億 token 不一定意味著用戶量很大也可能意味著每次請求都在反復傳輸大量歷史記錄?！?0億”這個數字如果來自項目演示可以是模型處理過的數據也可以是為了支持這個 AI 角色而準備的高質量監督語料。這里可以按兩種常見情況去理解一類是模型累計消耗的 token 量另一類是訓練或檢索階段處理過的 token 量。不同含義對應完全不同的成本優化策略落地前要先弄清楚自己的項目屬于哪一種。2.3 token 用量的優化與成本控制手段如果“70億 token”是每次調用累加出來的模型消耗優化空間就是所有 AI Agent 項目的共同課題。優化手段具體做法收益精簡 system prompt把角色規則壓縮成穩定、可檢索的固定文本每次請求固定省幾百 token歷史消息裁剪只保留最近若干輪舊對話轉成摘要避免請求長度隨對話線性增長工具返回精簡讓函數只返回必要字段減少機器生成文本進入上下文緩存相似請求對常見問答做 embedding 檢索或結果緩存減少重復模型調用用戶級限額為每個用戶設置每日 token 上限和提醒防止單個用戶耗盡預算日志審計記錄每次請求的 prompt_tokens 和 completion_tokens成本異常時可追溯本地跑通 Demo 時這些優化可以完全不管因為單次調用成本很低。生產環境必須設置模型調用守護閾值當某段時間內 token 消耗超過閾值時自動降級到更小的模型或暫停新請求。它是成本層面的“熔斷器”。還要記住一點在引入 RAG 或 Function Calling 后檢索出來的文檔和工具返回結果也會進入上下文這兩項通常被開發者忽略卻是 token 上漲的重要原因。3. 登錄時的 token exchange failed 到底錯在哪里3.1 OAuth/OIDC 登錄鏈路上token exchange 扮演什么角色很多 AI 應用并不是自己注冊用戶而是通過 GitHub、Google、OpenAI 等第三方身份源登錄。用戶在頁面看到一個很大的“Sign in with XX”按鈕背后走的是 OAuth 2.0 或 OIDC 授權碼流程用戶點擊登錄前端跳轉到身份提供方的授權頁。用戶確認授權后身份提供方帶一個 authorization code 跳回應用。應用后端拿著 authorization code 到身份提供方的 token endpoint 換取 access token。后端再通過 access token 拉取用戶信息構建自己的登錄態。第三步里“拿 code 換 token”的過程就是 token exchange。熱搜詞中反復出現的“sign-in could not be completed token exchange failed: token endpoint returned status 403”就發生在這一步。它說明應用已經拿到了 authorization code但在向身份服務方索要 access token 時被服務端拒絕了。3.2 一條真實的報錯鏈路403 forbidden 的定位有一類報錯信息非常長但拆開看并不復雜sign-in could not be completed token exchange failed: token endpoint returned status 403 forbidden: country, region, or territory not supported這句話可以拆成幾層sign-in could not be completed用戶側登錄流程中止。token exchange failed授權碼換 access token 失敗。token endpoint returned status 403身份提供方返回了 403說明請求已經到達服務端但被策略拒絕。country, region, or territory not supported服務商基于來源區域或賬戶區域做了限制。生產環境遇到這條報錯不建議去繞區域限制而是按下面順序核對當前用戶或當前服務器所在區域是否在服務商支持范圍內。服務商后臺賬戶是否完成了對應區域的啟用或白名單配置?？蛻舳?ID、客戶端密鑰是否配置正確。授權碼是否已經使用過OAuth 授權碼通常是一次性的重復使用會返回 invalid_grant。重定向 URI 是否和申請時填寫的一致包括協議、域名、端口、結尾斜杠。系統時間是否準確如果服務器時間偏差過大JWT 相關的有效期校驗會失敗。這張表可以當排查速查表用報錯現象常見原因檢查方式處理建議403 forbidden: country...服務商區域策略查看服務商官方支持列表和賬戶配置按官方渠道確認區域支持情況403 forbidden客戶端密鑰錯誤或已重置核對環境變量中的 client id / secret重新生成密鑰并更新配置invalid_grant授權碼已使用或過期檢查授權碼使用次數重新發起一次完整登錄流程redirect_uri_mismatch回調地址不一致對比申請時配置和實際回調地址統一大小寫、端口和路徑401 unauthorizedaccess token 過期或格式錯誤用日志記錄 token 前綴和簽發時間接入刷新機制而不是讓用戶反復登錄3.3 常見 token 失效場景與對癥處理token 失效不只有“過期”這一種原因。在 AI 監督學習這類需要長時間在線、用戶可能隔幾天再打開的頁面里常見失效場景有access token 過期默認生命周期短比如 30 分鐘到 2 小時。用戶長時間不操作后繼續發請求會收到 401。refresh token 過期生命周期通常是一周到一個月過期后需要用戶重新登錄。服務端主動吊銷用戶修改密碼、被踢下線、管理員禁用賬號后歷史 token 全部失效。登錄態只在內存里應用重啟后 session 或內存緩存丟失用戶被迫重新登錄。同賬號多設備互踢新登錄后舊的 refresh token 被標記失效。對癥處理時先看失效是“過期類”還是“吊銷類”。過期類走刷新流程吊銷類通常需要提示用戶重新認證而不是無限刷新。3.4 cookie、session、token 三種會話方案怎么選開發 AI 監督助手時會話方案不是越新越好而是要看場景。方案數據存儲位置服務端是否記錄狀態跨域支持主要風險適用場景Cookie瀏覽器默認自動攜帶可無狀態也可關聯 session較弱需要額外配置 CORSCSRF傳統服務端渲染頁面Session服務端內存或 Redis是強狀態一般服務端擴容需要共享存儲單體 Web 應用Token客戶端存儲請求頭攜帶通常無狀態好XSS 竊取API 服務、前后端分離、移動端AI Agent 項目通常是前后端分離后端提供 API前端可能是網頁、小程序或桌面端所以 token 方案更常見。JWT 只是 token 的一種編碼形式不是必須。如果服務端需要隨時吊銷某個會話純無狀態 JWT 不太方便需要在 Redis 里保存撤銷列表或刷新 token 狀態。4. 用 access token refresh token 做登錄續簽避免監督學習中斷4.1 為什么需要續簽而不是讓登錄一次永久有效如果 access token 設置成永久有效界面確實方便但安全性很低被竊取后無法吊銷長期有效意味著攻擊者可一直使用。對學習監督應用來說用戶不希望學到一半被踢回登錄頁但完全不刷新又不行。折中的方案是雙 token 機制access token有效期短比如 30 分鐘專門用于請求業務接口。refresh token有效期長比如 7 天只用于換取新的 access token。access token 過期后前端檢測到 401不直接跳登錄頁而是拿 refresh token 調一次刷新接口。刷新成功就繼續原請求刷新失敗才要求重新登錄。4.2 JWT 最小續簽設計JWT 由三部分組成Header、Payload、Signature。示例 payload 可以這樣設計{ sub: user_20240901, iss: study-supervisor, iat: 1725200000, exp: 1725201800, jti: token-uuid, scope: refresh }sub用戶 ID。iat / exp簽發時間和過期時間。jtitoken 唯一 ID用于吊銷和防重放。scope區分 access token 和 refresh token。服務端解析時先驗簽名再驗證 exp再檢查 jti 是否在撤銷列表里。不要把角色權限等大量數據都塞進 tokentoken 變大后每次請求頭都會增大刷新也不方便。4.3 刷新接口的 Java 示例下面給出一個簡化版刷新邏輯演示核心流程。以 JJWT 作為 JWT 庫為例實際項目需要根據版本調整依賴和方法名稱。PostMapping(/auth/refresh) public TokenResponse refresh(RequestBody RefreshRequest request) { String refreshToken request.getRefreshToken(); // 1. 解析 refresh token 并校驗簽名、有效期 Claims claims Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(refreshToken) .getBody(); if (!refresh.equals(claims.get(scope))) { throw new UnauthorizedException(當前 token 不是 refresh token); } String jti claims.getId(); if (refreshTokenStore.isRevoked(jti)) { throw new UnauthorizedException(refresh token 已撤銷); } // 2. 簽發新的 access token String userId AI監督學習應用：70億token的成本控制與登錄續簽全解析
在 B站 AI 創造公開賽 上“70億 token做了個 AI 德國軍官監督我學習”是一個很容易被點開的項目它把大模型從被動的問答工具變成了一個會施壓、會監督、會反饋的學習伙伴。但從開發者視角看這個標題更值得注意的不是“德國軍官”而是“70億 token”和“AI 監督”背后的工程成本與登錄體驗問題。這類項目表面上是一個創意 demo實際落地時會遇到三個非常具體的工程問題大模型 token 消耗怎么估算和控制AI 角色如何在多輪對話里保持穩定用戶登錄狀態如何在長期使用中不頻繁中斷。熱搜詞里大量出現的 token 失效、token exchange failed、JWT 續簽都和這些問題直接相關。下面從工程角度把這個項目拆開重點講清楚 token 相關的成本模型、登錄報錯排查和續簽設計。1. 先拆解“AI 德國軍官監督學習”這類項目的真正難點1.1 表面是創意本質是完整的人機交互閉環“AI 德國軍官監督我學習”不是一個單純的聊天機器人。用戶打開頁面后看到的不是一個溫柔的回答框而是一個有固定性格、會定時提醒、會檢查進度、會用嚴肅語氣反饋的角色。要實現這個效果至少需要四條鏈路交互入口用戶輸入文字或者通過語音與 AI 對話。角色引擎大模型按設定好的軍官人格、語氣、規則生成回復。任務狀態系統需要知道用戶當前學什么、學到哪里、距離截止時間還有多久。反饋閉環用戶提交學習成果后AI 判斷是否達標并輸出夸獎、批評或新的任務安排。用一張表描述模塊。模塊承擔職責常見落地技術角色設定固定“德國軍官”的人設、語氣、行為邊界system prompt 提示詞模板對話交互接收用戶輸入并生成回復大模型 Chat Completions API語音能力把 AI 回復變成語音或把用戶語音轉成文字TTS / ASR任務管理記錄學習目標、起止時間、完成狀態Redis / MySQL / KV 存儲監督觸發定時提醒、超時警告、進度檢查定時任務 消息推送這些模塊共同構成一個“AI Agent”而不是“AI 客服”。用戶在頁面上看到的是一段自然對話但背后每一次消息都要經過狀態查詢、提示詞組裝、模型調用、結果校驗和記錄存儲。1.2 三個躲不開的工程問題角色、成本、登錄態實際開發中最容易讓項目卡住的不是“大模型能不能生成軍官語氣”而是下面三個問題。第一個是角色穩定性。“德國軍官”的設定寫在 system prompt 里但多輪對話之后模型可能忘記規則語氣越來越隨意。這個問題不能靠繼續堆提示詞解決而是要在會話構建時把關鍵規則固定在最前面并用結構化輸出約束模型的判斷結果。第二個是成本與性能。每一個監督互動都需要攜帶角色設定、近期對話歷史、當前任務狀態。調用次數一多token 消耗就變成一筆必須面對的成本。標題里的“70億 token”放在工程語境里就是整個系統累計消耗的 token 數量級。第三個是登錄態。如果這個項目只在自己電腦上演示登錄可以不考慮。但只要部署到公網多人使用或者需要把學習記錄長期保存在服務器就必須有用戶體系。用戶體系一旦引入token 失效、過期、刷新、退出登錄就會成為頻繁出現的故障點。這三個問題對應了后面的內容先看 token 成本和角色設定再看認證 token 的報錯和續簽最后落到上線檢查清單。1.3 哪些讀者會從中拿到實際收益以下幾個場景比較典型正在寫 AI Agent 項目但不知道如何估算大模型 token 消耗。在接入第三方登錄或 AI 服務時撞到 token exchange failed不知道從哪查起。被 401、403、refresh token 過期反復打斷想設計一個完整的登錄續簽方案。想把“AI 監督學習”“AI 虛擬角色”這類創意做成可上線、可長期服務用戶的產品。如果你的目標只是跑通一個 Demo可以直接復制提示詞如果想讓它穩定地跑一個學期就必須把后面的工程問題補齊。2. “70億 token”到底指的是什么AI 應用的算力成本模型2.1 認證 token 和大模型 token 是兩回事在討論報錯之前先做一個概念區分。開發 AI 項目時“token”這個詞會出現兩次。第一次出現在用戶登錄系統里access token、refresh token 是訪問憑據作用是告訴服務器“當前請求來自哪個用戶”。第二次出現在大模型調用里模型會把文本切成一個個 token 來理解上下文。token 是文本長度和計算量的基本單位。熱搜詞里大量出現“token失效”“JWT實現token續簽”“cookie session token區別”這些屬于用戶登錄鏈路而標題里的“70億 token”更接近大模型調用量。兩個 token 名字相同但職責完全不同排查問題時如果混在一起很容易走彎路。2.2 70 億 token 消耗的估算思路在 LLM 應用中一次對話請求的 token 消耗不能只看用戶輸入的一句話。以監督學習場景為例一次發給模型的請求通常由四部分組成系統指令軍官人格、行為規則、監督流程可能占 800 到 1500 token。歷史消息之前幾輪對話內容尤其當上下文窗口很長時歷史會占據大頭。用戶當前消息文字可能很短語音轉文字后可能更長。模型輸出AI 軍官評分、催促、布置任務一般幾百到上千 token。粗略估算可以這樣算單次請求 token 約等于“系統指令 歷史消息 當前用戶消息 模型輸出 工具返回內容”。假設平均每次監督互動消耗 6000 token那么 70億 token 大約對應 116 萬次請求。如果平均請求更長比如 20000 token則只有 35 萬次。這個換算關系說明70億 token 不一定意味著用戶量很大也可能意味著每次請求都在反復傳輸大量歷史記錄?！?0億”這個數字如果來自項目演示可以是模型處理過的數據也可以是為了支持這個 AI 角色而準備的高質量監督語料。這里可以按兩種常見情況去理解一類是模型累計消耗的 token 量另一類是訓練或檢索階段處理過的 token 量。不同含義對應完全不同的成本優化策略落地前要先弄清楚自己的項目屬于哪一種。2.3 token 用量的優化與成本控制手段如果“70億 token”是每次調用累加出來的模型消耗優化空間就是所有 AI Agent 項目的共同課題。優化手段具體做法收益精簡 system prompt把角色規則壓縮成穩定、可檢索的固定文本每次請求固定省幾百 token歷史消息裁剪只保留最近若干輪舊對話轉成摘要避免請求長度隨對話線性增長工具返回精簡讓函數只返回必要字段減少機器生成文本進入上下文緩存相似請求對常見問答做 embedding 檢索或結果緩存減少重復模型調用用戶級限額為每個用戶設置每日 token 上限和提醒防止單個用戶耗盡預算日志審計記錄每次請求的 prompt_tokens 和 completion_tokens成本異常時可追溯本地跑通 Demo 時這些優化可以完全不管因為單次調用成本很低。生產環境必須設置模型調用守護閾值當某段時間內 token 消耗超過閾值時自動降級到更小的模型或暫停新請求。它是成本層面的“熔斷器”。還要記住一點在引入 RAG 或 Function Calling 后檢索出來的文檔和工具返回結果也會進入上下文這兩項通常被開發者忽略卻是 token 上漲的重要原因。3. 登錄時的 token exchange failed 到底錯在哪里3.1 OAuth/OIDC 登錄鏈路上token exchange 扮演什么角色很多 AI 應用并不是自己注冊用戶而是通過 GitHub、Google、OpenAI 等第三方身份源登錄。用戶在頁面看到一個很大的“Sign in with XX”按鈕背后走的是 OAuth 2.0 或 OIDC 授權碼流程用戶點擊登錄前端跳轉到身份提供方的授權頁。用戶確認授權后身份提供方帶一個 authorization code 跳回應用。應用后端拿著 authorization code 到身份提供方的 token endpoint 換取 access token。后端再通過 access token 拉取用戶信息構建自己的登錄態。第三步里“拿 code 換 token”的過程就是 token exchange。熱搜詞中反復出現的“sign-in could not be completed token exchange failed: token endpoint returned status 403”就發生在這一步。它說明應用已經拿到了 authorization code但在向身份服務方索要 access token 時被服務端拒絕了。3.2 一條真實的報錯鏈路403 forbidden 的定位有一類報錯信息非常長但拆開看并不復雜sign-in could not be completed token exchange failed: token endpoint returned status 403 forbidden: country, region, or territory not supported這句話可以拆成幾層sign-in could not be completed用戶側登錄流程中止。token exchange failed授權碼換 access token 失敗。token endpoint returned status 403身份提供方返回了 403說明請求已經到達服務端但被策略拒絕。country, region, or territory not supported服務商基于來源區域或賬戶區域做了限制。生產環境遇到這條報錯不建議去繞區域限制而是按下面順序核對當前用戶或當前服務器所在區域是否在服務商支持范圍內。服務商后臺賬戶是否完成了對應區域的啟用或白名單配置?？蛻舳?ID、客戶端密鑰是否配置正確。授權碼是否已經使用過OAuth 授權碼通常是一次性的重復使用會返回 invalid_grant。重定向 URI 是否和申請時填寫的一致包括協議、域名、端口、結尾斜杠。系統時間是否準確如果服務器時間偏差過大JWT 相關的有效期校驗會失敗。這張表可以當排查速查表用報錯現象常見原因檢查方式處理建議403 forbidden: country...服務商區域策略查看服務商官方支持列表和賬戶配置按官方渠道確認區域支持情況403 forbidden客戶端密鑰錯誤或已重置核對環境變量中的 client id / secret重新生成密鑰并更新配置invalid_grant授權碼已使用或過期檢查授權碼使用次數重新發起一次完整登錄流程redirect_uri_mismatch回調地址不一致對比申請時配置和實際回調地址統一大小寫、端口和路徑401 unauthorizedaccess token 過期或格式錯誤用日志記錄 token 前綴和簽發時間接入刷新機制而不是讓用戶反復登錄3.3 常見 token 失效場景與對癥處理token 失效不只有“過期”這一種原因。在 AI 監督學習這類需要長時間在線、用戶可能隔幾天再打開的頁面里常見失效場景有access token 過期默認生命周期短比如 30 分鐘到 2 小時。用戶長時間不操作后繼續發請求會收到 401。refresh token 過期生命周期通常是一周到一個月過期后需要用戶重新登錄。服務端主動吊銷用戶修改密碼、被踢下線、管理員禁用賬號后歷史 token 全部失效。登錄態只在內存里應用重啟后 session 或內存緩存丟失用戶被迫重新登錄。同賬號多設備互踢新登錄后舊的 refresh token 被標記失效。對癥處理時先看失效是“過期類”還是“吊銷類”。過期類走刷新流程吊銷類通常需要提示用戶重新認證而不是無限刷新。3.4 cookie、session、token 三種會話方案怎么選開發 AI 監督助手時會話方案不是越新越好而是要看場景。方案數據存儲位置服務端是否記錄狀態跨域支持主要風險適用場景Cookie瀏覽器默認自動攜帶可無狀態也可關聯 session較弱需要額外配置 CORSCSRF傳統服務端渲染頁面Session服務端內存或 Redis是強狀態一般服務端擴容需要共享存儲單體 Web 應用Token客戶端存儲請求頭攜帶通常無狀態好XSS 竊取API 服務、前后端分離、移動端AI Agent 項目通常是前后端分離后端提供 API前端可能是網頁、小程序或桌面端所以 token 方案更常見。JWT 只是 token 的一種編碼形式不是必須。如果服務端需要隨時吊銷某個會話純無狀態 JWT 不太方便需要在 Redis 里保存撤銷列表或刷新 token 狀態。4. 用 access token refresh token 做登錄續簽避免監督學習中斷4.1 為什么需要續簽而不是讓登錄一次永久有效如果 access token 設置成永久有效界面確實方便但安全性很低被竊取后無法吊銷長期有效意味著攻擊者可一直使用。對學習監督應用來說用戶不希望學到一半被踢回登錄頁但完全不刷新又不行。折中的方案是雙 token 機制access token有效期短比如 30 分鐘專門用于請求業務接口。refresh token有效期長比如 7 天只用于換取新的 access token。access token 過期后前端檢測到 401不直接跳登錄頁而是拿 refresh token 調一次刷新接口。刷新成功就繼續原請求刷新失敗才要求重新登錄。4.2 JWT 最小續簽設計JWT 由三部分組成Header、Payload、Signature。示例 payload 可以這樣設計{ sub: user_20240901, iss: study-supervisor, iat: 1725200000, exp: 1725201800, jti: token-uuid, scope: refresh }sub用戶 ID。iat / exp簽發時間和過期時間。jtitoken 唯一 ID用于吊銷和防重放。scope區分 access token 和 refresh token。服務端解析時先驗簽名再驗證 exp再檢查 jti 是否在撤銷列表里。不要把角色權限等大量數據都塞進 tokentoken 變大后每次請求頭都會增大刷新也不方便。4.3 刷新接口的 Java 示例下面給出一個簡化版刷新邏輯演示核心流程。以 JJWT 作為 JWT 庫為例實際項目需要根據版本調整依賴和方法名稱。PostMapping(/auth/refresh) public TokenResponse refresh(RequestBody RefreshRequest request) { String refreshToken request.getRefreshToken(); // 1. 解析 refresh token 并校驗簽名、有效期 Claims claims Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(refreshToken) .getBody(); if (!refresh.equals(claims.get(scope))) { throw new UnauthorizedException(當前 token 不是 refresh token); } String jti claims.getId(); if (refreshTokenStore.isRevoked(jti)) { throw new UnauthorizedException(refresh token 已撤銷); } // 2. 簽發新的 access token String userId