WordPress后台权限“粗”因其仅支持角色+能力的粗粒度控制，无法实现模块差异化、插件/菜单动态隐藏、行级数据控制及权限继承；CI4可构建独立RBAC服务，通过五表结构、规范命名、API校验与Redis缓存补足该短板。
WordPress后台权限颗粒度偏粗，原生只支持“管理员”“编辑”“作者”等角色级别控制，无法按菜单、按钮、插件甚至具体字段做细粒度拦截；而CodeIgniter 4（CI4）本身不内置RBAC，需手动搭建或引入扩展。要让两者协同工作——比如用CI4构建独立权限服务，再对接WP后台行为——关键在于绕过WP的粗粒度限制，把权限判断逻辑外移、细化、可编程。
WP后台权限为什么“粗”？
WordPress默认权限基于角色（Role）+能力（Capability）模型，例如manage_options决定能否进设置页，edit_posts控制文章编辑权。但它不支持：
- 同一角色下对不同模块差异化授权（如“编辑”角色能改A栏目但不能碰B栏目）
- 按用户动态隐藏某个插件或某项菜单（除非用
all_plugins钩子硬过滤） - 数据行级控制（如教师只能看本班学生成绩）
- 权限继承与层级（如staff继承teacher全部能力，再叠加审核权）
这些正是RBAC要解决的问题，而WP没提供现成机制。
CI4作为RBAC中枢的设计要点
用CI4单独搭一套RBAC服务，不是替代WP，而是补足它的短板。核心是把权限判定从WP内核里“抽出来”，交由CI4统一管理：
- 五张基础表必须齐备：users（WP用户同步过来）、roles、permissions、user_roles、role_permissions —— 不要省略关联表，否则无法支持多角色、多权限组合
-
权限命名遵循资源:操作规范，例如
plugin:elementor.view、menu:tools.import、score:grade.read，便于前端和中间件直接比对 -
提供HTTP API供WP调用，比如WP插件在加载菜单前请求
/ci4/permission/check?user_id=123&permission=menu:resources.upload，CI4返回true/false - 缓存权限关系：用户登录后，把其所有权限名一次性查出并写入Redis，后续校验走缓存，避免每次请求都查5张表
让WP菜单和插件响应CI4权限
WP侧不改核心，只加轻量钩子，把显示逻辑交给CI4结果驱动：
- 隐藏插件：用
all_plugins过滤器，先获取当前用户ID，再调CI4接口，仅当返回true才保留该插件条目 - 动态菜单：在
admin_menu钩子里，遍历$GLOBALS['menu']，对每个菜单项检查对应权限码（如menu:resources），无权则unset() - 按钮级控制：前端JS读取用户权限列表（可由WP REST API透传CI4返回的权限数组），用
v-if="hasPermission('resource:upload')"控制按钮显隐 - 关键：所有前端控制必须配后端二次校验，WP的AJAX处理函数开头就应调CI4权限接口，拒绝非法请求
不用框架也能起步的最小可行方案
如果暂时不想跑两个应用，可在WP里用CI4风格模拟RBAC：
- 新建wp_terms表中建自定义分类
rbac_role和rbac_permission，用wp_term_relationships做关联 - 写一个
WP_Rbac_Manager类，封装userCan($user_id, $permission)方法，内部执行JOIN查询 - 把权限码写死在代码里（如
if (WP_Rbac_Manager::userCan(get_current_user_id(), 'plugin:seo.edit')) { ... }） - 虽不如CI4灵活，但已能突破WP原生能力边界，适合中小项目快速落地
不复杂但容易忽略：权限变更后务必清掉相关缓存，否则用户登出再登录也不生效。
