Web 權限設計實戰（上）：三大主流方案深度對比與數據庫建模

前言：權限系統的核心挑戰

權限控制是 Web 應用安全的基石。本文系統梳理三大主流實現方案，並給出生產級數據庫設計雛形，為後續細節實作奠基。

一、三大主流權限實現方案深度對比

1. 手動實現（攔截器模式）

核心機制：配置兩個攔截器——LoginInterceptor 驗證登錄態，PermissionInterceptor 匹配 URL 權限。通過「角色-權限-資源」映射表，將請求 URL 與配置的權限 URL 模式匹配。

• 優點：完全可控、輕量、無框架依賴、易於定制業務邏輯（如多租戶、動態權限）。
• 缺點：需自行處理會話管理、CSRF、Session 共享等安全細節；URL 模式匹配易產生漏洞（如 /admin/* 繞過）；維護成本隨系統膨脹急劇上升。
• 適用場景：中小型項目、極簡原型、強定制化需求、團隊具備安全開發能力。

2. Spring Security（重量級正規軍）

核心機制：基於 Servlet Filter 鏈，提供認證、授權、CSRF、Session 管理、OAuth2、LDAP 等開箱即用功能。核心組件：FilterChainProxy、AuthenticationManager、AccessDecisionManager。

• 優點：功能最全、社區最活躍、Spring 生態無縫整合、企業級安全標準。
• 缺點：學習曲線極陡峭、配置極其複雜、啟動較慢、對非標準場景擴展困難（需深入源碼）。
• 適用場景：大型企業級應用、微服務安全統一、需符合合規審計、團隊有專人維護安全棧。

3. Apache Shiro（輕量級實戰派）

核心機制：核心三件套——Subject（用戶主體）、SecurityManager（安全管理器）、Realm（數據源適配）。不依賴 Spring，可獨立運行，亦可輕鬆整合。

• 優點：API 直觀簡潔、權限粒度細（至按鈕/字段）、配置簡單、性能優異、易於單元測試。
• 缺點：Spring 生態整合不如 Spring Security 深度（如無原生 WebFlux 支持）；社區活躍度下降（近年更新緩慢）；OAuth2/OpenID Connect 需第三方擴展。
• 適用場景：中大型傳統 Spring MVC 項目、追求開發效率與可維護性平衡、團隊偏好輕量框架。

> **趨勢提示**：Spring 官方已推出 Spring Authorization Server 並大力推廣 Spring Security 6+，Shiro 逐漸邊緣化。新項目建議優先評估 Spring Security 或輕量替代方案（如 Sa-Token）。

二、生產級權限數據庫設計（核心表結構）

採用經典 RBAC（基於角色的訪問控制） 模型，支撐「用戶-角色-權限-資源」四元關係。下圖為核心表結構 ER 圖（普通版，後續將擴展字段支撐數據權限、租戶隔離等）：

核心表說明

表名	職責	關鍵字段
sys_user	用戶主表	id, username, password, salt, status, create_time
sys_role	角色定義	id, code, name, description, data_scope
sys_permission	權限/資源定義	id, parent_id, type(menu/button/api), path, perms, component
sys_user_role	用戶-角色關聯	user_id, role_id
sys_role_permission	角色-權限關聯	role_id, permission_id

擴展預留字段（下版本將詳細展開）

• sys_role.data_scope：數據權限範圍（1全部 2本部門 3本部門及子部門 4僅本人）
• sys_permission.type：區分菜單、按鈕、API 接口，支撐前端路由動態生成與後端精細攔截
• sys_tenant + 關聯表：多租戶隔離支撐

三、下期預告

下篇將深入實戰：

1. Shiro 核心配置與 Realm 實現（含緩存、加密、會話管理）
2. 前端權限指令（v-permission）與路由守衛實現
3. 動態權限刷新機制（無需重新登錄）
4. 數據權限（行級/列級）實現方案