一、面试官的「灵魂拷问」
面试官微笑着说："来，设计一个企业级权限管理系统。"
我心里一紧。这不是简单的"增删改查"，而是B端产品的核心基础设施。
我深吸一口气，开始拆解...
二、题意拆解：面试官到底在考什么？
表面看是考功能设计，实际是考三层能力：
| 考察维度 | 核心考点 | 面试官期待 |
|---|---|---|
| 业务抽象 | RBAC vs ABAC | 知道什么时候用什么 |
| 架构思维 | 数据模型 + 接口设计 | 能支撑百万级用户 |
| 场景覆盖 | 数据权限 + 功能权限 | 边界条件考虑周全 |
三、核心论点：3个关键设计决策
论点1：RBAC是地基，ABAC是天花板
RBAC（基于角色的访问控制）解决80%的场景：
• 用户 → 角色 → 权限 → 资源
• 适合组织架构清晰的企业
ABAC（基于属性的访问控制）解决复杂场景：
• 规则："部门=销售部 AND 职级≥经理"
• 适合动态、细粒度的权限需求
论点2：权限判定要「预计算 + 实时校验」双轨制
• 用户登录时：预计算角色权限 → 写入缓存
• 访问资源时：实时校验数据权限 → 防止越权
论点3：数据权限比功能权限更难做
功能权限："能不能点这个按钮"
数据权限："能不能看这条数据"
后者需要解决行级、列级、字段级的精细控制
四、高分答案示例：系统架构全景图
1. 核心数据模型
# 用户-角色-权限模型（RBAC）
class User:
user_id: string # 用户唯一标识
roles: List[Role] # 多角色支持
dept_id: string # 所属部门（用于数据权限）
class Role:
role_id: string
permissions: List[Permission]
data_rules: List[DataRule] # 数据权限规则
class Permission:
resource: string # 资源标识：order:read
action: enum # CREATE/READ/UPDATE/DELETE
2. 权限校验流程
# 权限校验伪代码
def check_permission(user, resource, action):
# 1. 功能权限校验（查缓存）
if not has_function_permission(user, resource, action):
return False
# 2. 数据权限校验（实时计算）
data_filter = build_data_filter(user, resource)
return data_filter
3. 数据权限规则引擎
| 规则类型 | 示例 | 适用场景 |
|---|---|---|
| 行级规则 | dept_id = user.dept_id | 只能看本部门数据 |
| 列级规则 | hide columns: salary, phone | 敏感字段脱敏 |
| 字段级规则 | amount > 10000 需审批 | 业务规则触发 |
⚠️ 面试官避坑指南
• 别忘了考虑权限继承（部门主管自动拥有下属权限）
• 别忘了权限回收（员工离职/调岗时的处理）
• 别忘了性能优化（权限变更时的缓存失效策略）
五、反向追问：给面试官的「钩子」
回答完后，主动抛出这些问题，展示你的深度思考：
1. 关于扩展性：
"如果未来需要支持跨租户权限（SaaS多租户场景），您建议如何调整当前架构？"
2. 关于安全：
"在零信任架构下，权限校验应该放在网关层还是服务层？各自的优劣是什么？"
3. 关于业务：
"贵司的权限场景更偏向强流程管控（如金融）还是灵活协作（如互联网）？这会影响规则引擎的设计偏向。"
六、总结
权限管理是B端产品的「地基工程」。
好的权限设计要做到：
✅ 模型清晰：RBAC + ABAC 分层
✅ 性能可控：预计算 + 实时校验
✅ 场景覆盖：功能 + 数据 + 字段三级权限
💡 核心认知：权限系统不是功能堆砌，而是业务规则的技术化表达。理解业务，才能设计好权限。
