PHP 權限系統設計：四種常見模型與位運算/質數/向量實現對比

權限模型分類

權限值編碼策略對比

1. 2 的冪次位掩碼（主流推薦）

權限常量：READ=1 (2^0), ADD=2 (2^1), EDIT=4 (2^2), DELETE=8 (2^3)...
用戶權限值 = 位或組合：$perm = READ | ADD | EDIT; // = 7
判斷：($perm & DELETE) !== 0  → 有刪除權限
優點：極快、單整數存儲、位運算原子性、易擴展（新增權限只需新常量）。
缺點：權限數超過 64 位需大整數或多字段；無法直接表達「刪除包含閱讀」等業務邏輯（需上層代碼保證授予 READ）。

2. 質數乘積編碼

權限質數：READ=2, ADD=3, EDIT=5, DELETE=7...
用戶權限 = 乘積：$perm = 2*3*5 = 30 (READ+ADD+EDIT)
判斷：$perm % 5 === 0 → 有 EDIT
缺點：數值增長極快（幾個權限即超 64 位）、質因數分解慢、難以維護、業務邏輯同樣無法內建包含關系。不推薦生產使用。

3. 定長字符串向量（位圖字符串）

順序固定：READ,ADD,EDIT,DELETE...
用戶權限 = '1101' (有 READ,ADD,DELETE)
擴展：在末尾追加字符，舊數據自動補 0。
優點：無位數上限、直觀可讀、易於數據庫 LIKE 查詢。
缺點：存儲空間大、字符串操作比位運算慢、需固定順序嚴格維護。

4. 作者早期「目錄+操作」雙層模型

欄目權限：用戶可訪問目錄數組（如 ['news','product']）
操作權限：瀏覽/添加/修改/刪除 → 對應文件命名規則（proAddEdit.php?id=... 判斷修改）
缺點：強耦合文件結構、不支持 OOP/框架路由、難以單元測試、擴展性差。已過時。

最佳實踐建議（現代 PHP 專案）

1. 採用 RBAC（角色基礎訪問控制）：用戶→角色→權限，角色由業務定義（如「編輯」「審核」「管理員」）。
2. 權限粒度到「動作」：article.create, article.update, article.delete, article.publish 等字符串標識。
3. 數據庫結構：

   roles (id, name, slug)
   permissions (id, name, slug, description)
   role_permissions (role_id, permission_id)
   user_roles (user_id, role_id)

4. 代碼層面：
   • 中間件/基類控制器：$this->authorize('article.update', $article)
   • 策略類：ArticlePolicy::update(User $user, Article $article) 封裝複雜業務規則（如作者本人、管理員、發布狀態）。
   • Blade/Vue 指令：@can('article.delete', $article) 控制 UI 顯示。
5. 性能優化：用戶權限集合登入時緩存至 Redis/Session，避免每請求查庫；位掩碼仍可用於高頻檢查的內存判斷。

總結

位掩碼（2 的冪次）是底層存儲與判斷的最高效方案，但業務層應封裝為語義化的權限字符串/策略類。避免質數乘積、定長向量、文件耦合等反模式。現代框架（Laravel Gates/Policies、Symfony Voters、ThinkPHP Auth）已提供成熟 RBAC 實現，建議直接使用而非重複造輪子。