题目重点：按账户树向上合并角色，反向查询有效用户，再解释空过滤器、层级方向与权限快照。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练按accountId形成无环账户树，parent角色向child继承；描述中“each user有parent”与给定accounts输入不一致，实际父子对象需先确认。
- 角色为字符串集合，仅允许加法继承、不含deny、优先级或时间有效期；正式若有deny，简单union失效。
- 角色filter为全部满足，空filter返回已有至少一个有效角色的用户，而非系统里所有未分配权限的用户；这是需要确认的查询域。
解题路线
- 先把直接assignment存成account→user→role set。相同(user,account,role)重复赋权不重复返回；未知账户、环、缺失parent需报错或明示政策，不无限向上走。
- 查询user在target账户的有效角色，遍历target及其全部ancestor，把各层该user的role合并。注意是向祖先读权限，不是自动把子账户授予的role传播到parent或兄弟账户。
- 反向查询账户用户，仍遍历祖先链，把每个ancestor上有assignment的user聚合角色。只取target直接assignment会漏从org继承权限的用户。
- ALL filter计算required⊆effective_roles，而不是两集合交集非空。用户有admin但缺viewer时不能通过[admin,viewer]；重复filter项去重不改变结果。
- 空filter对任何集合都满足子集关系，但候选user集合仍由查询域决定。若要求系统全部用户，应显式给全局user注册表；仅有assignment输入不能枚举从未分配角色的用户。
- 多次读取可缓存effective_roles，但ancestor赋权撤销会影响整个子树。带版本号的缓存/快照可避免撤权后一段时间仍过期授权；权限判定需要明确允许的失效窗口，不能只看性能。
- 生产权限还需要deny、账号合并、时间有效期与审计。本文纯加法树合同仅证明union正确，不把“更高层admin”擅自解释为拥有所有角色。角色名与功能授权关系是另一策略层。
手动走一遍
org→workspace。org给alice=admin，workspace给alice=viewer与bob=viewer。查询workspace：alice有效{admin,viewer}，bob{viewer}；filter[admin,viewer]只返回alice，filter[]返回alice/bob。查org不能看到workspace给bob的viewer。
规模与取舍
单用户查询O(H+A_u)，H为祖先深度、A_u为沿链该用户角色总量。反向查询O(H+A)，A为沿链全部assignment，过滤再按用户和filter大小计；预计算可加速读但祖先变更可能O(子树有效权限规模)刷新。
易错点与追问
容易失分的边界
- 把user parent与account parent混为一谈。
- 向子树查祖先继承。
- ALL过滤写成ANY。
- 空filter自动返回所有系统用户。
- 祖先撤权后缓存无限期有效。
继续深挖
- deny优先时怎样定义合并？
- 账户有多个parent变DAG怎么避免重复？
- 权限变更与一次请求如何绑定快照？
- 怎样做反向索引而不漏继承用户？
