Webman中RBAC权限系统必须在中间件统一拦截校验、角色权限关联不绕过casbin_rule表、用户权限缓存带版本号并与角色变更联动；否则将导致权限失效或性能崩塌。
Webman 中实现 RBAC 权限系统，核心不是“装个插件就完事”，而是必须明确三件事：权限校验点必须在中间件层统一拦截、角色与权限的关联不能绕过 casbin_rule 表、用户权限缓存必须带版本号且与角色变更联动。跳过任意一环，都会导致权限失效或性能崩塌。
为什么不能直接查库做权限判断
每次请求都走 SELECT * FROM sys_role JOIN sys_role_permission JOIN sys_permission 是最常见也最危险的做法——它让权限校验从 O(1) 退化为 O(N)，并发稍高就拖垮数据库。更严重的是，这种写法无法利用 Casbin 的策略匹配能力（比如 keyMatch 处理 /api/v1/users/* 这类通配路径）。
- 真实项目中，90% 的“权限明明配了却不生效”问题，根源是中间件里写了
if (!Auth::can($code))却没提前调用Auth::setUser($uid)，导致内部始终查不到用户上下文 - Casbin 的
Enforcer实例必须复用，不能每个请求 new 一个——否则规则加载、适配器初始化开销会吃掉毫秒级响应优势 - ThinkORM 默认开启查询日志，上线前务必关掉，否则每条权限检查都会多一次
INSERT INTO query_log写入
casbin_rule 表字段怎么填才不丢权限
casbin_rule 不是随便塞数据的地方。它的 ptype、v0、v1、v2 四个字段必须严格对应模型定义，否则 enforcer.enforce("user1", "/admin/user", "delete") 永远返回 false。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- RBAC 模型下，
ptype = "p"表示普通策略，v0 = "role_admin"（角色名），v1 = "/admin/user"（资源路径），v2 = "delete"（动作）；若填成v0 = "user1"就退化成 ACL，失去角色继承能力 - 超级用户规则必须单独加一行：
ptype = "g"，v0 = "user1"，v1 = "root"，再配一条p, root, *, *—— 缺少g行，root角色不会被自动赋予 -
v1字段值必须和路由定义完全一致：后端接口是@POST("/api/v1/orders/{id}")，策略里就得写/api/v1/orders/*，写成/orders/*或/api/v1/orders都会不匹配
前端菜单和按钮权限怎么和后端对齐
前后端权限不一致，根本原因不是“同步机制没写好”，而是前端把权限当配置、后端把权限当逻辑——两边校验依据必须同源。Mini RBAC 的做法是：后端只暴露 GET /api/v1/user/menus 返回扁平菜单树（含 permission_code），前端用它驱动 router.addRoutes() 和 v-if="hasPermission('user:edit')"。
- 菜单接口返回的每个节点必须带
code字段（如"user:list"），不能只传name或path——因为同一路径可能对应多个权限（如/user页面，查看需user:list，导出需user:export） - 按钮权限不要用 DOM ID 判断，而要绑定到组件级响应式数据：
btnPerms来自 store 初始化时拉取的权限数组 - 绝对禁止前端自己拼接权限码（如
`${route.name}:${action}`），一旦路由名重构，所有按钮权限集体失效
权限缓存失效后怎么避免雪崩
用户在后台改完角色，前端页面刷新后仍显示旧菜单，不是前端没重拉接口，而是后端 /user/menus 接口返回了 Redis 里的 stale 数据。缓存键设计错了，比没缓存还危险。
- 缓存 key 必须包含用户 ID 和权限版本号，例如
"user_menu_123_v7"，版本号存在独立的sys_role_version表里，每次角色权限变更就UPDATE该表并DEL user_menu_*_v7 - 不要用
$_SESSION['permissions']存权限数组——PHP-FPM 进程间 session 不共享，用户在 A 机器登录、B 机器访问，权限就是空的 - ThinkORM 查询缓存默认不识别参数变化，
$this->where('uid', $uid)->cache(true)->select()会把第一次的$uid=1结果缓存住，后续$uid=2也返回 uid=1 的数据
