CodeIgniter可通过钩子、自定义库和会话管理实现RBAC；关键在于权限校验时机（post_controller_constructor钩子）、节点命名规范（模块.控制器.方法三段式）、SESSION中仅存角色ID或哈希标识而非全量节点列表。
CodeIgniter 框架本身不内置 RBAC，但可以通过钩子（Hooks）、自定义库和会话管理快速搭出可用的权限控制层。关键不是“能不能做”，而是**权限校验时机、角色-节点映射方式、以及 SESSION 中权限数据的结构是否合理**——这三点踩错一个，后续就容易出现漏放行、误拦截或缓存失效问题。
权限校验必须放在 post_controller_constructor 钩子里
很多开发者把权限检查写在基类控制器的 __construct() 里，结果发现 AJAX 请求、API 接口或某些跳转路径绕过了校验。
原因在于 CI 的执行顺序：post_controller_constructor 是控制器实例化完成、但任何方法（包括 index()）还没执行前的最后统一入口，比 pre_controller 更稳妥，也避免了在每个控制器里重复写逻辑。
- 必须在
application/config/hooks.php中启用该钩子，并确保$config['enable_hooks'] = TRUE - 钩子函数里要能拿到当前请求的模块/控制器/方法（即
$this->router->fetch_class()和$this->router->fetch_method()） - 不要在校验失败时直接
redirect()，而应抛出 HTTP 状态码（如 403）或设置标志位，让视图层统一处理——否则会影响 API 返回格式
Rbac 类中节点（node）怎么定义才不容易翻车
CI 的 RBAC 常见错误是把“节点”粗暴等同于“URL 路径”，比如 manage/User/edit。这样会导致两个问题：一是 URL 改动就得同步改权限表；二是无法支持同一控制器下按参数粒度控制（如只允许编辑自己的文章）。
更稳妥的做法是用“模块.控制器.方法”三段式命名，例如 manage.user.edit 或 api.post.list，再配合数据库中的 privilege_code 字段存储。这样：
- 权限数据可脱离路由规则独立维护
- 前端按钮显隐、菜单折叠都能复用同一套 code 判断
- 后期加数据级权限（如
manage.user.edit:own）时扩展成本低
注意：rbac_manage_node_hidden 这类配置项只影响后台菜单渲染，**不影响实际访问控制**，别误以为设了它就能跳过权限校验。
SESSION 中存权限数据，别存全量数组
有些实现把用户所有可访问的节点列表（几十上百个字符串）直接塞进 $_SESSION['rbac_nodes']，短期没问题，但一旦角色权限变更，旧 SESSION 不会自动刷新，用户得重新登录才能生效。
推荐做法是只存角色 ID（role_id）或哈希标识（如 rbac_role_hash），每次请求时动态查库或查缓存。如果担心性能，可用 Redis 缓存 “role_id → nodes” 映射，设置 TTL 为 5–10 分钟，兼顾一致性与响应速度。
- 绝对不要在钩子中调用
$this->session->set_userdata()写大量数据——CI 的 session 类在钩子阶段可能尚未完全初始化 - 若坚持存节点列表，请在用户修改角色后主动清空对应 session key，而不是依赖过期
- 测试时重点验证：角色被移除某权限后，已登录用户是否在下一次请求就被拦截
真正难的不是把五张表连起来，而是让权限判断既快又准，且不破坏 CI 原有请求生命周期。钩子位置、节点命名规范、SESSION 存什么——这三个点定下来，RBAC 就稳了一大半。
