权限继承不会自动发生，必须显式配置：ZooKeeper中子节点不继承父节点ACL，默认使用开放权限；面向对象继承仅复用代码结构，不传递访问控制；实际系统需通过业务层封装、祖先遍历校验或RBAC路径匹配等方式模拟。
用户权限继承不是自动发生的，Parent-Child关系本身不带来权限传递。无论是ZooKeeper的ACL、面向对象编程中的类继承，还是文件系统或数据库的权限模型，权限都不会默认从父级“流”向子级——必须显式配置或主动设计才能实现类似效果。
ZooKeeper中节点权限不继承
ZooKeeper明确禁止ACL自动继承。创建子节点时，若未指定ACL，系统会使用Ids.OPEN_ACL_UNSAFE（即完全开放），而非复用父节点的权限设置。这意味着：
- 父节点设为仅
auth:admin可读写，子节点仍可能被任何人创建或删除 - 每个节点ACL需单独管理，不能依赖层级结构做统一管控
- 如需“类继承式”权限控制，必须在业务层封装逻辑，例如：创建子节点时强制读取父节点ACL并复用
面向对象中“继承”不等于“权限继承”
类的继承（如Java/Python/C++中Child extends Parent）是代码结构复用机制，与访问控制权限无关。它解决的是“能用什么方法/属性”，而不是“谁有权访问”。关键事实包括：
- 子类可以调用父类
public或protected成员，但这是语言语法允许，不是权限委派 -
private成员虽被继承（存在于子类对象内存布局中），但子类代码无法直接访问 - 没有运行时“权限提升”或“委托授权”；子类实例不会因继承而获得对父类资源的额外访问权
实际系统中模拟“权限继承”的常见做法
当业务需要父子级权限联动时，通常靠约定+编码实现，而非底层机制支持：
- 在创建子资源（如ZooKeeper子节点、数据库记录、API资源）时，主动获取父资源ACL并复制过去
- 权限校验阶段，向上遍历祖先节点，检查任一父级是否授予了当前用户所需权限（即“祖先任意满足即通过”）
- 用RBAC模型配合资源路径表达式，例如
/org/{id}/project/**匹配所有子项目，统一赋权 - 引入中间服务做权限代理，把
user → parent → child的访问链路转化为一次策略决策
本质上，Parent-Child是一种结构关系，权限是独立策略。把二者耦合，得靠设计，不是靠默认。
