做AI SaaS平臺這兩年我最大的體會就是權(quán)限體系這種東西看著不起眼真到了模型一多、用戶一多、租戶一多的時候它會變成整個系統(tǒng)里最容易出事故、也最難改的一塊。之前我們平臺剛起步時權(quán)限就兩個角色管理員和普通用戶菜單里藏一下按鈕就完事了。后來接入的AI能力越來越重有的租戶要調(diào)GPT-4o有的只需要輕量摘要還有人要按調(diào)用次數(shù)計費(fèi)這時候才發(fā)現(xiàn)權(quán)限不是“誰能登錄后臺”的問題而是“誰能調(diào)用什么模型、能用多少額度、能看哪些數(shù)據(jù)”的立體問題。這篇文章就圍繞如何用RBAC基于角色的訪問控制實(shí)戰(zhàn)落地一套AI SaaS平臺的權(quán)限體系展開。我盡量講清楚整個設(shè)計鏈路從數(shù)據(jù)表怎么建、權(quán)限點(diǎn)怎么命名、到模型調(diào)用怎么鑒權(quán)、配額怎么扣、審計日志怎么做再到實(shí)際開發(fā)中哪些坑最容易踩。適合正在做SaaS平臺、AI應(yīng)用后端、或者準(zhǔn)備重構(gòu)權(quán)限模塊的團(tuán)隊參考也適合剛接觸權(quán)限設(shè)計的后端工程師至少能幫你少走幾條彎路。1. 為什么AI SaaS平臺的權(quán)限體系不能只靠“登錄 角色”1.1 傳統(tǒng)后臺權(quán)限和AI SaaS平臺的差異傳統(tǒng)的后臺權(quán)限管理通常解決的是“誰能進(jìn)入哪個頁面、誰能點(diǎn)哪個按鈕”的問題。用戶登錄后拿到一個角色角色關(guān)聯(lián)一批菜單和操作權(quán)限后端接口再做一下攔截基本就完事了。這種模型在純信息管理類系統(tǒng)里非常成熟也是RBAC最經(jīng)典的應(yīng)用場景。但放到AI SaaS平臺上事情變復(fù)雜了因?yàn)槟阋刂频馁Y源不只是頁面和按鈕還包括AI模型本身的調(diào)用、Token額度、并發(fā)數(shù)、數(shù)據(jù)隔離范圍、甚至不同模型的不同版本。舉個例子我們平臺上有一個客戶成功團(tuán)隊和一個開發(fā)者團(tuán)隊前者只能白屏操作調(diào)用摘要模型后者需要直接調(diào)API并且可以配置prompt模板。如果只按“管理員/普通用戶”分要么開發(fā)者拿到過多權(quán)限要么客戶成功團(tuán)隊什么都干不了。更麻煩的是AI模型調(diào)用是有成本的和合規(guī)要求的你不光要管“能不能調(diào)”還要管“能調(diào)幾次”“能調(diào)哪個模型”“調(diào)完之后日志留沒留下”這些已經(jīng)不是傳統(tǒng)RBAC能直接覆蓋的范圍了。所以說AI SaaS平臺的權(quán)限體系本質(zhì)上是在傳統(tǒng)RBAC之上疊加了資源權(quán)限、配額權(quán)限、租戶數(shù)據(jù)權(quán)限和審計要求。RBAC依然是最穩(wěn)的底座但必須在底座上做擴(kuò)展。1.2 RBAC模型怎么選從RBAC0到RBAC2再到RBACABAC很多同學(xué)知道RBAC但不一定清楚RBAC本身也分幾個級別。做設(shè)計之前先把模型選對能省掉后面大量返工。RBAC0用戶直接關(guān)聯(lián)權(quán)限沒有角色這層抽象。小項(xiàng)目能用但一旦權(quán)限一多用戶和權(quán)限之間直接爆炸基本不推薦。RBAC1引入角色繼承角色可以嵌套。比如“運(yùn)營”繼承“基礎(chǔ)用戶”的所有權(quán)限再額外加一些導(dǎo)出權(quán)限。這種模型很適合權(quán)限有天然層級關(guān)系的平臺。RBAC2引入角色約束包括角色互斥用戶不能同時擁有兩個互斥角色、角色基數(shù)每個角色的人數(shù)上限、先決角色要擁有某角色必須先有另一個角色。這在金融、企業(yè)服務(wù)里很常見。RBAC3RBAC1RBAC2既支持繼承又帶約束能力最全但復(fù)雜度也最高。我實(shí)際做AI SaaS平臺時建議主體用RBAC1加部分RBAC2的約束比如“模型管理員”和“財務(wù)管理員”做成互斥角色避免權(quán)限過度集中。至于那種需要根據(jù)上下文動態(tài)判斷的場景比如“只允許在工作時間調(diào)用敏感模型”或者“同一個角色在不同租戶下看到不同數(shù)據(jù)”純RBAC處理不了我會額外引入ABAC策略來補(bǔ)充而不是把RBAC硬拗成萬能模型。這里說一個很實(shí)用的判斷標(biāo)準(zhǔn)如果權(quán)限判斷的依據(jù)是“用戶身份是什么”用RBAC如果依據(jù)是“請求時的環(huán)境、資源屬性、上下文”用ABAC。AI SaaS平臺里前者解決90%的問題后者解決最后那些動態(tài)規(guī)則。1.3 純RBAC和ABAC結(jié)合的落地思路純ABAC的問題在于規(guī)則太難維護(hù)。你讓業(yè)務(wù)去寫幾十條策略表達(dá)式他們根本看不懂。但RBAC的好處是直觀——給某個角色勾選權(quán)限點(diǎn)產(chǎn)品經(jīng)理和業(yè)務(wù)都看得明白。所以我的落地思路是先把系統(tǒng)里所有可控制的動作抽象成權(quán)限點(diǎn)關(guān)聯(lián)到角色上這部分全部走RBAC。在此基礎(chǔ)上再留一個規(guī)則引擎擴(kuò)展點(diǎn)專門承接“限時可用”“限資源可用”這類臨時策略。比如某天要上線一個灰度模型只允許白名單租戶調(diào)用我就在規(guī)則引擎里加一條“當(dāng)租戶ID在whiteList時允許訪問model:invoke:new-model”而底層角色權(quán)限完全不用動。這樣既保住了RBAC的簡單性又不至于在動態(tài)需求面前束手無策。后面章節(jié)里的表結(jié)構(gòu)設(shè)計也完全兼容這種“RBAC為主、ABAC為補(bǔ)充”的方案。2. 權(quán)限模型設(shè)計核心表結(jié)構(gòu)與關(guān)鍵字段解析2.1 五張核心表的SQL設(shè)計權(quán)限系統(tǒng)的地基是表結(jié)構(gòu)尤其要注意不要設(shè)計成“用戶表里塞一個role字段”這種省事方案。后期你要查“哪些用戶擁有某個權(quán)限”“某個角色都關(guān)聯(lián)了什么權(quán)限”的時候一張冗余字段表會讓你想罵人。我推薦至少五張表用戶表、角色表、權(quán)限表、用戶-角色關(guān)聯(lián)表、角色-權(quán)限關(guān)聯(lián)表。字段上不一定要完全照抄我的設(shè)計但以下這些核心點(diǎn)值得保留。CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1啟用 0禁用, tenant_id BIGINT NOT NULL COMMENT 所屬租戶, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE sys_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_code VARCHAR(64) NOT NULL UNIQUE COMMENT 角色編碼如 MODEL_ADMIN, role_name VARCHAR(64) NOT NULL, parent_id BIGINT DEFAULT NULL COMMENT 父角色I(xiàn)D支持角色繼承, status TINYINT NOT NULL DEFAULT 1, tenant_id BIGINT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_permission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, perm_code VARCHAR(128) NOT NULL UNIQUE COMMENT 權(quán)限點(diǎn)編碼如 model:invoke:gpt-4o, perm_name VARCHAR(128) NOT NULL, category VARCHAR(64) DEFAULT NULL COMMENT 分組如 MODEL_ACCESS / QUOTA / AUDIT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_user_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, tenant_id BIGINT NOT NULL, UNIQUE KEY uk_user_role (user_id, role_id) ); CREATE TABLE sys_role_permission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_id BIGINT NOT NULL, permission_id BIGINT NOT NULL, UNIQUE KEY uk_role_perm (role_id, permission_id) );這里有一個重要細(xì)節(jié)所有業(yè)務(wù)表都加了tenant_id。原因很簡單SaaS平臺天然多租戶如果權(quán)限表本身不按租戶隔離后面做數(shù)據(jù)權(quán)限會非常痛苦。雖然sys_permission可以做成全局共享但角色和用戶的關(guān)系必須綁定租戶。比如A租戶的“模型管理員”和B租戶的“模型管理員”同名但數(shù)據(jù)完全不能互通。2.2 中間表為什么要存在而不是用戶表直接帶角色I(xiàn)D寫單表快但你會立即撞上“一人多角色”這種需求。產(chǎn)品經(jīng)理大概率會說“這個用戶既是模型管理員又是審計員他的權(quán)限是兩者疊加?！比绻阍谟脩舯砝镏环乓粋€role_id這需求直接做不了。用中間表可以支持多對多多角色時權(quán)限取并集這個其實(shí)很簡單但要注意權(quán)限疊加可能導(dǎo)致越權(quán)。比如一個角色有“導(dǎo)出用戶數(shù)據(jù)”權(quán)限另一個角色剛好有“查看所有租戶”的數(shù)據(jù)范圍權(quán)限兩者疊加就可能把全平臺數(shù)據(jù)導(dǎo)出。遇到這種情況就要在RBAC2里加約束或者靠權(quán)限審批流程來控制后面我會在“常見問題”里展開講。2.3 把權(quán)限點(diǎn)設(shè)計成“資源標(biāo)識”統(tǒng)一命名與路由映射權(quán)限點(diǎn)編碼是整個體系中容易被低估的設(shè)計。很多團(tuán)隊直接寫“用戶管理”“模型管理”這種中文命名短期能用但接口一多、模型一多維護(hù)起來就是災(zāi)難。我建議用三段式命名模塊:動作:資源。模塊通常對應(yīng)系統(tǒng)域動作是動詞資源是被操作的對象。例如model:invoke:gpt-4o 表示允許調(diào)用GPT-4o模型model:invoke:gpt-4o-mini 表示允許調(diào)用輕量模型quota:update:user 表示允許調(diào)整用戶配額audit:view:log 表示允許查看審計日志prompt:write:template 表示允許編寫提示詞模板后端做校驗(yàn)時直接在接口代碼里聲明需要的權(quán)限點(diǎn)例如“調(diào)用模型接口需要model:invoke:gpt-4o”。前端拉取權(quán)限點(diǎn)列表后控制菜單顯隱、按鈕狀態(tài)。這樣前后端用同一套權(quán)限點(diǎn)編碼理解成本低排查問題也方便。權(quán)限點(diǎn)不建議用數(shù)據(jù)庫自增ID直接傳給前端因?yàn)镮D在不同環(huán)境可能不一致容易出現(xiàn)測試環(huán)境正常、生產(chǎn)環(huán)境錯亂的靈異問題。用字符串編碼做唯一標(biāo)識天然可讀、可遷移環(huán)境切換幾乎沒有成本。2.4 數(shù)據(jù)權(quán)限與租戶隔離容易被忽略的維度角色權(quán)限解決的是“能不能操作”數(shù)據(jù)權(quán)限解決的是“能操作哪些數(shù)據(jù)”。在AI SaaS平臺里這兩個維度必須分開設(shè)計。舉個例子兩個租戶都開通了某個模型服務(wù)如果接口鑒權(quán)只校驗(yàn)角色不校驗(yàn)租戶ID用戶用A租戶的token調(diào)用接口傳入的卻是B租戶的模型配置ID就可能讀取到其他租戶的數(shù)據(jù)。這種越權(quán)在AI應(yīng)用里非常隱蔽。我通常這么處理先按RBAC判斷“能不能做”再按數(shù)據(jù)權(quán)限過濾“能做哪些”。數(shù)據(jù)權(quán)限分三級就夠了全部數(shù)據(jù)、本部門/本租戶數(shù)據(jù)、僅本人數(shù)據(jù)。具體的隔離方式SaaS平臺一般有三種選擇隔離方式說明適合場景獨(dú)立數(shù)據(jù)庫每個租戶一個庫隔離最徹底大型客戶、合規(guī)要求高獨(dú)立Schema同庫不同Schema中型SaaS共享表 tenant_id所有租戶共用同一張表行級隔離中小型SaaS起步期我建議絕大多數(shù)AI SaaS平臺起步階段用“共享表 tenant_id”成本最低也最靈活。關(guān)鍵是要有一個全局的TenantContext比如基于ThreadLocal或請求上下文把當(dāng)前租戶ID塞進(jìn)去然后所有的數(shù)據(jù)訪問層都強(qiáng)制帶上tenant_id條件不允許靠開發(fā)人員自覺。3. 結(jié)合AI能力擴(kuò)展模型調(diào)用權(quán)限、配額與審計3.1 把AI模型當(dāng)作受控資源模型網(wǎng)關(guān)設(shè)計AI SaaS平臺和普通SaaS最不一樣的地方就是底層API全是模型調(diào)用。模型不是免費(fèi)資源也不是隨便哪個角色都能碰所以要把模型當(dāng)成一類“資源”來管理。我的做法是加一層模型網(wǎng)關(guān)所有模型調(diào)用統(tǒng)一走網(wǎng)關(guān)不在業(yè)務(wù)代碼里直接拼OpenAI或者其他廠商的SDK調(diào)用。模型網(wǎng)關(guān)的核心職責(zé)有三個鑒權(quán)、配額校驗(yàn)、轉(zhuǎn)發(fā)。所謂的“模型權(quán)限”本質(zhì)上就是網(wǎng)關(guān)里的一組白名單配置判斷當(dāng)前用戶所在的角色是否擁有目標(biāo)模型的調(diào)用權(quán)限。{ model: gpt-4o, allowed_roles: [ROLE_MODEL_ADMIN, ROLE_ENTERPRISE_USER], allowed_plans: [enterprise, pro], rate_limit: { rpm: 60, tpm: 100000 }, quota_cost: 20 }上面這個配置的意思是只有模型管理員和企業(yè)用戶角色能調(diào)用gpt-4o且套餐必須是enterprise或pro每分鐘最多60次請求每次調(diào)用消耗20個credits。網(wǎng)關(guān)拿到請求后先解析用戶角色再和配置比對不滿足直接返回403滿足就進(jìn)入配額扣減流程。這個設(shè)計的優(yōu)點(diǎn)很明顯新增一個模型只需在網(wǎng)關(guān)里加配置不需要改一堆業(yè)務(wù)代碼。比如平臺接入了新的圖像生成模型要開放給運(yùn)營角色只需要在網(wǎng)關(guān)配置里把運(yùn)營角色加進(jìn)白名單再設(shè)置好配額成本前后端代碼零改動。3.2 Credits配額設(shè)計權(quán)限不只是“能不能用”還要管“用多少”AI模型按調(diào)用量計費(fèi)所以權(quán)限系統(tǒng)必須對接配額系統(tǒng)。很多團(tuán)隊一開始不做配額結(jié)果月底賬單出來老板傻眼。配額本質(zhì)上是一張“余額表”記錄每個用戶或角色在某個周期內(nèi)可用多少次模型調(diào)用。Credits在AI產(chǎn)品里通常指計量配額。我的方案是用戶賬戶表里存總credits余額模型配置表里存每次調(diào)用消耗多少credits每次調(diào)用前做余額預(yù)校驗(yàn)不足直接拒絕調(diào)用成功后異步扣費(fèi)失敗則返還這里有一個非常容易出問題的點(diǎn)并發(fā)扣費(fèi)。用戶連續(xù)點(diǎn)了幾次“生成圖片”如果業(yè)務(wù)代碼是“先查余額再判斷再扣減”并發(fā)請求可能同時通過校驗(yàn)導(dǎo)致余額變成負(fù)數(shù)。解決方式是用Redis的Lua腳本做原子扣減或者用數(shù)據(jù)庫樂觀鎖。我習(xí)慣在網(wǎng)關(guān)里直接做預(yù)扣這樣效率高一點(diǎn)-- 簡單演示原子扣減 credits local current tonumber(redis.call(GET, KEYS[1]) or 0) local cost tonumber(ARGV[1]) if current cost then return -1 else redis.call(DECRBY, KEYS[1], cost) return current - cost end扣減完成后再去調(diào)模型API萬一模型調(diào)用失敗再執(zhí)行“返還”邏輯給用戶的credits加回去。這個“預(yù)扣-回調(diào)-返還”的流程比調(diào)用成功后再扣費(fèi)可靠得多因?yàn)槟Ｐ驼{(diào)用是網(wǎng)絡(luò)IO超時、報錯太常見了調(diào)用成功后再扣費(fèi)很容易漏扣。3.3 審計與內(nèi)容安全AI場景更容易出問題傳統(tǒng)后臺的審計日志記“誰刪了什么數(shù)據(jù)”就夠了AI SaaS平臺的審計更復(fù)雜。你得知道誰在什么時間調(diào)用了哪個模型、傳了什么輸入、模型返回了什么摘要。一方面是為了排查濫用另一方面是為了滿足合規(guī)要求。我的建議是至少維護(hù)一張審計表CREATE TABLE ai_audit_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, tenant_id BIGINT NOT NULL, model_code VARCHAR(64) NOT NULL, action VARCHAR(32) NOT NULL COMMENT invoke / retry / fallback, prompt_hash VARCHAR(64) DEFAULT NULL COMMENT 輸入內(nèi)容哈希用于溯源, prompt_text TEXT DEFAULT NULL COMMENT 輸入內(nèi)容需要脫敏, output_text TEXT DEFAULT NULL COMMENT 輸出內(nèi)容摘要, cost_credits INT NOT NULL DEFAULT 0, status TINYINT NOT NULL COMMENT 0失敗 1成功, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_user_time (user_id, created_at), KEY idx_tenant_time (tenant_id, created_at) );注意prompt_text和output_text必須脫敏不能直接原樣存尤其是涉及用戶隱私或企業(yè)機(jī)密的內(nèi)容。實(shí)際操作里我會先跑一遍脫敏規(guī)則把手機(jī)號、郵箱、身份證號替換掉再落庫。內(nèi)容安全層面AI生成內(nèi)容需要接入合規(guī)檢測檢測不通過要攔截返回。這個可以放在模型網(wǎng)關(guān)里做模型調(diào)用前先對輸入做審查輸出回來后對內(nèi)容做審查兩邊都不放過。我們之前就踩過輸出側(cè)漏審的坑用戶輸入本身合規(guī)但模型生成的文案里帶了違規(guī)內(nèi)容好在有輸出檢測兜底否則問題就大了。4. 鑒權(quán)實(shí)現(xiàn)從登錄態(tài)到權(quán)限校驗(yàn)的完整鏈路4.1 登錄態(tài)與JWT權(quán)限信息放哪里權(quán)限設(shè)計得再好最終都要落到鑒權(quán)執(zhí)行鏈路上。最常見的方案是用JWT做登錄態(tài)用戶在登錄后拿到一個token后續(xù)請求帶token訪問。問題來了JWT里到底放不放權(quán)限信息我見過有人把用戶所有權(quán)限點(diǎn)塞進(jìn)JWT省得每次查庫。但這樣做有兩個坑一是JWT是無狀態(tài)的權(quán)限變更后舊的token依然有效導(dǎo)致權(quán)限更新不及時二是JWT體積膨脹每次請求都帶著一大串權(quán)限列表浪費(fèi)帶寬。我的做法是JWT里只放用戶ID、租戶ID、角色編碼列表這些輕量信息不放全量權(quán)限點(diǎn)。每次請求進(jìn)來后用用戶ID去緩存里拿權(quán)限點(diǎn)集合。權(quán)限變更時通過版本號機(jī)制讓緩存失效這樣既保證了實(shí)時性又不會把token撐得很大。// 偽代碼JWT payload 示例 { sub: u_12345, tenant: tenant_678, roles: [ROLE_MODEL_ADMIN], perm_version: 12, exp: 1710000000 }perm_version是一個自增版本號每次該用戶的角色或權(quán)限變更版本號加1緩存里的權(quán)限數(shù)據(jù)也跟著刷新。網(wǎng)關(guān)里只用判斷JWT的perm_version和緩存里的版本是否一致不一致就重新加載權(quán)限不用重啟服務(wù)。4.2 后端權(quán)限攔截基于注解加自定義校驗(yàn)器后端接口權(quán)限校驗(yàn)我推薦直接用Spring Security加方法級注解或者用AOP自定義一個權(quán)限注解。Spring Security生態(tài)成熟但自定義注解更輕量適合不想被框架綁得太死的團(tuán)隊。我通常定義一個RequirePermission的注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequirePermission { String value(); }然后在需要權(quán)限的接口上標(biāo)注PostMapping(/v1/model/invoke) RequirePermission(model:invoke:gpt-4o) public Result invokeModel(RequestBody InvokeRequest request) { // 業(yè)務(wù)邏輯 }再寫一個切面在方法執(zhí)行前攔截校驗(yàn)當(dāng)前用戶是否擁有指定權(quán)限點(diǎn)Aspect Component public class PermissionAspect { Around(annotation(requirePermission)) public Object checkPermission(ProceedingJoinPoint joinPoint, RequirePermission requirePermission) throws Throwable { PermissionContext ctx PermissionContextHolder.get(); if (!ctx.hasPermission(requirePermission.value())) { throw new ForbiddenException(requirePermission.value()); } return joinPoint.proceed(); } }這樣做的好處是權(quán)限判斷和業(yè)務(wù)邏輯完全解耦代碼里能看到每個接口明確的權(quán)限要求后面接新的AI模型也只需要標(biāo)注對應(yīng)的權(quán)限點(diǎn)。缺點(diǎn)也有如果一個接口有多個權(quán)限點(diǎn)注解只能寫一個這時可以把注解改成支持字符串?dāng)?shù)組校驗(yàn)時滿足任一即可或者改成必須全部滿足看業(yè)務(wù)需要。4.3 前端按鈕級權(quán)限控制與菜單動態(tài)化后端校驗(yàn)做完了前端如果不配合體驗(yàn)會很糟。用戶看到一堆點(diǎn)不進(jìn)去的菜單肯定會困惑。所以前端也要根據(jù)權(quán)限點(diǎn)動態(tài)控制界面元素。登錄成功后后端返回當(dāng)前用戶擁有的權(quán)限點(diǎn)列表前端存起來。然后寫一個v-permission指令控制按鈕顯隱// Vue 3 指令示例 app.directive(permission, { mounted(el, binding) { const required binding.value; const userPerms store.state.userPerms; if (!userPerms.includes(required)) { el.parentNode el.parentNode.removeChild(el); } } });模板里這樣用el-button v-permissionmodel:invoke:gpt-4o調(diào)用GPT-4o/el-button菜單動態(tài)化同理后端返回菜單樹的時候每個菜單項(xiàng)都綁定權(quán)限點(diǎn)編碼前端渲染前先過濾一遍沒有權(quán)限的菜單直接不渲染。這里強(qiáng)烈建議前后端權(quán)限點(diǎn)編碼完全一致不要前端一套、后端一套否則排查起來要命。4.4 緩存權(quán)限Redis加速與一致性權(quán)限校驗(yàn)走數(shù)據(jù)庫是能跑但高并發(fā)下數(shù)據(jù)庫壓力太大。我建議把用戶權(quán)限點(diǎn)列表緩存到Redis里key類似perm:user:{userId}value是權(quán)限點(diǎn)集合的JSON數(shù)組。緩存之后要考慮失效問題。權(quán)限變更時除了更新數(shù)據(jù)庫還要主動刪除Redis緩存。由于JWT里有perm_version也可以約定每次請求帶著版本號網(wǎng)關(guān)發(fā)現(xiàn)版本落后就主動刷新這樣即使Redis被誤刪也能自動重建。不過緩存只是加速手段不能作為唯一數(shù)據(jù)源。高安全場景下寫操作確認(rèn)權(quán)限前最好回源數(shù)據(jù)庫校驗(yàn)一次權(quán)限避免緩存數(shù)據(jù)被篡改導(dǎo)致越權(quán)。大多數(shù)平臺沒那么高要求Redis緩存就夠了。5. 常見問題與排查技巧實(shí)錄5.1 改了角色權(quán)限用戶還是能訪問舊功能這是最常遇到的問題十有八九是緩存或token導(dǎo)致的。JWT里塞了權(quán)限列表的token沒過期之前權(quán)限當(dāng)然不變Redis緩存沒刪的同樣會讀到舊權(quán)限。排查思路三步走第一步看JWT里有沒有權(quán)限數(shù)據(jù)第二步看Redis緩存里有沒有舊數(shù)據(jù)第三步看權(quán)限變更接口有沒有主動刪緩存。我見過一個團(tuán)隊的問題是權(quán)限變更接口改了數(shù)據(jù)庫但緩存刪除代碼在一個新加的事務(wù)里事務(wù)回滾了緩存卻被刪了于是權(quán)限刷新和數(shù)據(jù)庫狀態(tài)不一致排查了整整一下午。所以緩存和數(shù)據(jù)庫的操作順序一定要設(shè)計好我的習(xí)慣是先更新數(shù)據(jù)庫再刪緩存緩存刪除失敗要做重試。5.2 并發(fā)扣費(fèi)導(dǎo)致配額超扣上文提到的并發(fā)問題我再展開講一個真實(shí)案例。我們上線初期某個客戶用腳本并發(fā)調(diào)用了20次接口結(jié)果余額從1000被扣到負(fù)數(shù)雖然模型調(diào)用全成功了但對賬就是不對。根因還是“先查余額再扣費(fèi)”不是原子操作。用數(shù)據(jù)庫樂觀鎖能修但性能差一點(diǎn)。我后來改用了Redis的Lua腳本把“檢查余額、扣減、返回剩余”放在一個腳本里執(zhí)行Redis保證腳本原子性徹底解決了并發(fā)問題。如果你們沒有Redis也可以用數(shù)據(jù)庫原子更新比如UPDATE account SET credits credits - 20 WHERE credits 20受影響的記錄數(shù)為0就說明余額不足這個SQL本身是原子的。5.3 角色多、權(quán)限矩陣亂怎么治理正常來說權(quán)限點(diǎn)控制在100個以內(nèi)角色控制在20個以內(nèi)維護(hù)起來問題不大。一旦角色超過30個權(quán)限矩陣基本就會失控。我的建議是定期做角色收斂。把權(quán)限點(diǎn)高度重疊的角色合并用用戶組而不是多角色來解決“一批人總是擁有相同角色”的需求。另外每次給角色加權(quán)限點(diǎn)時都要反問一句“這個權(quán)限真的需要放到角色上嗎能不能用ABAC規(guī)則做臨時開通”權(quán)限點(diǎn)不是越多越好每多一個權(quán)限點(diǎn)就多一分越權(quán)的可能。5.4 多租戶數(shù)據(jù)越權(quán)訪問全局?jǐn)r截器兜底多租戶SaaS最危險的場景就是A租戶的用戶傳入B租戶的資源ID接口如果沒有做租戶隔離數(shù)據(jù)就泄露了。光靠開發(fā)人員在SQL里寫where tenant_id ?往往不夠因?yàn)槿硕紩?。我建議做一個全局MyBatis攔截器或者在ORM層統(tǒng)一注入租戶條件。比如MyBatis-Plus就有租戶插件配置好tenant_id字段后所有自動拼接的SQL都會帶上租戶條件。這樣即便開發(fā)者漏寫了框架也會兜底。前提是你能接受所有表都有tenant_id字段這個設(shè)計需要前期規(guī)劃好后期臨時加非常痛苦。5.5 權(quán)限點(diǎn)編碼錯誤排查還有一個細(xì)節(jié)權(quán)限點(diǎn)編碼是字符串一旦寫錯比如前端要求model:invoke:gpt-4o后端接口標(biāo)的是model:invoke:gpt4o用戶就會莫名看到按鈕被隱藏或者接口403。這種問題沒有好辦法只能靠規(guī)范。我建議權(quán)限點(diǎn)編碼統(tǒng)一用常量類或枚舉管理前后端從接口文檔自動生成類型定義避免手敲出錯。審核代碼的時候重點(diǎn)看權(quán)限點(diǎn)字符串是否全部來自常量引用而不是隨手寫的字面量。如果讓我重新把權(quán)限體系再做一遍我會把租戶隔離和審計日志放到最高優(yōu)先級因?yàn)檫@兩個東西一旦上線后想補(bǔ)成本比角色模型大多了。RBAC的核心思路不復(fù)雜復(fù)雜的是把“誰能在什么條件下做什么事”這個一句話需求拆成用戶、角色、權(quán)限點(diǎn)、數(shù)據(jù)范圍、配額、審計這六個維度并且讓它們各司其職又彼此協(xié)作。希望這篇實(shí)戰(zhàn)記錄能給你一些參考。