Phalcon ACL不支持原生角色继承，仅提供角色-资源-操作的显式权限绑定；需手动实现继承逻辑，如预计算权限集或封装checkAccess()方法，并注意大小写、资源名匹配及deny优先级等细节。
Phalcon 框架本身不内置 RBAC 或 ACL 角色继承机制，它的 Phalcon\Acl 组件是纯资源-权限控制模型（即“谁对什么能做什么”），不原生支持角色之间的父子继承关系。所谓“子角色继承父权限不生效”，本质不是配置漏了，而是误把 Phalcon ACL 当成了 Yii、Laravel 或 Nebular 那类带角色层级管理的权限系统。
确认你用的是原生 Phalcon ACL
Phalcon 的 Acl\Adapter\Memory 或 Database 仅提供三类核心能力：
- 添加角色（
addRole()）—— 仅注册一个角色名，不定义任何层级 - 添加资源（
addResource()）—— 如users、posts - 赋予权限（
allow()/deny()）—— 显式绑定某角色对某资源的某操作（如admin→users→update）
它没有 addChild()、没有 parent_id 字段、不递归检查祖先角色。如果你在代码里写了类似 $acl->addChild('editor', 'user')，这行会报错或静默失败——因为 Phalcon ACL 类根本没有这个方法。
想实现角色继承？必须自己编码补全
若业务需要“管理员继承编辑权限，编辑继承访客权限”，需在应用层手动实现逻辑，常见做法有：
-
预计算权限集：用户登录后，根据其角色查出所有直系+祖先角色，合并它们在 ACL 中被显式授予的权限，缓存为
user_permissions[user_id] = ['users.read', 'posts.create'] -
封装 checkAccess() 方法：不直接调用
$acl->isAllowed($role, $resource, $action)，而是先展开角色继承链，再逐个调用isAllowed()，任一返回 true 即放行 -
数据库建模支撑：新增
roles_hierarchy表，字段含child_role和parent_role，用递归查询或闭包表（Closure Table）管理多级继承
排查常见“不生效”的真实原因
即使你已自行实现了继承逻辑，以下细节仍极易导致判断失败：
- 角色名大小写不一致：Phalcon ACL 区分大小写，
'Admin'和'admin'被视为两个角色 - 资源名未完全匹配：允许的是
posts，但检查时传了post或Posts - 权限动作名拼写错误：定义了
edit，却检查update；或用了点号/冒号（如post.edit），而 ACL 只接受简单字符串 - 缓存未刷新：修改了数据库中的继承关系或权限规则，但没清空预计算的权限缓存（如 APCu/Redis 中的
acl_permissions_*键） - 未处理 deny 优先级：Phalcon ACL 中
deny()优先于allow()，若父角色被deny('users', 'delete')，子角色即使没被 deny，也无法获得该权限
替代建议：换更匹配的方案
如果角色继承是刚需，且不想重复造轮子，可考虑：
- 接入第三方库，如
spatie/laravel-permission（虽为 Laravel 设计，但其核心逻辑可剥离复用） - 改用支持 RBAC 的框架层权限模块（如基于 Phalcon 构建的扩展包
phalcon-acl-rbac，注意验证其维护状态） - 退回到简单策略模式：每个控制器方法用
if ($user->isEditor() || $user->isAdmin())显式判断——适合角色少、变化不频繁的场景
