RBAC权限校验必须放在中间件或路由装饰器层，不能在业务逻辑中手写if判断；FastAPI推荐用Depends依赖注入实现，Flask可用before_request或自定义装饰器，核心是将权限判定抽象为可复用单元。
RBAC权限校验该放在Flask/FastAPI的哪一层
必须放在中间件或路由装饰器层，不能在业务逻辑里手写if user.role != "admin"。否则权限规则散落各处，后期无法统一审计和变更。
FastAPI推荐用Depends依赖注入做权限校验；Flask可用before_request或自定义装饰器。关键是要把权限判定抽象成可复用的单元，比如一个require_permission函数，接收resource和action两个参数。
- 资源（resource）建议标准化为
"user"、"order:write"、"report:export"这类字符串，冒号后表示操作粒度 - 避免用数据库字段名（如
user.is_staff）做权限判断依据，它属于角色属性，不是权限本身 - 不要在视图函数里查用户所有权限再
in判断——N+1查询会拖慢接口，应预加载或缓存权限集
如何设计role-permission-resource三者关系表
标准RBAC四张表（user、role、permission、resource）容易过度设计。实际API权限管理中，resource和permission常合并为一个permission_code字段，例如"project:read"、"project:delete"。
推荐三张表：
user_role（用户-角色关联）、
role_permission（角色-权限码关联）、
permission（仅存权限码和描述，不存资源类型）
- 权限码必须全局唯一，且带语义，比如
"billing:invoice:create"比"can_create_invoice"更易追溯来源 - 不要给角色直接赋“所有项目权限”，而要拆成
"project:{id}:read"这种动态格式，运行时靠上下文补全{id} - 数据库索引至少加在
role_permission(role_id, permission_code)联合字段上，否则鉴权查询变全表扫描
动态权限（如数据级权限）怎么和RBAC结合
RBAC本身不处理“只看自己创建的订单”这类数据过滤逻辑，必须叠加行级安全（Row Level Security）或查询拦截。
立即学习“Python免费学习笔记（深入）”；
常见做法是在权限校验通过后，由统一的数据访问层（DAO）根据当前用户身份自动注入WHERE条件：
- 对
"order:read"权限，DAO自动追加WHERE user_id = current_user.id OR team_id IN (SELECT team_id FROM user_team WHERE user_id = current_user.id) - 不要让每个
get_order()方法都手动写过滤，应封装在OrderQueryBuilder之类工具类中 - 如果用SQLAlchemy，可用
event.listen(Query, "before_compile")全局拦截，但注意它不适用于原生SQL或session.execute() - 动态权限的权限码命名要有标识，比如
"order:read:own"vs"order:read:all"，便于审计时区分能力边界
缓存权限数据时最容易忽略的失效场景
权限变更后，用户下次请求仍可能命中旧缓存，导致“已删权限却还能访问”。Redis缓存user_id → set of permission_code时，必须保证三个失效点同步：
- 修改
user_role表后，立即DEL cache:user_permissions:{user_id} - 修改
role_permission表后，需遍历所有拥有该角色的用户ID批量删除（可用SCAN+DEL，或提前维护role:users集合） - 用户登出时清缓存，但更要防“登出未清”——建议设较短TTL（如15分钟），并用懒加载+后台刷新机制平衡一致性与性能
- 别用
user_id作为唯一缓存key，要带上版本号或更新时间戳，比如user_permissions:{user_id}:{role_updated_at}，避免并发更新丢失
最麻烦的是跨服务场景：权限服务改了，网关或业务服务缓存没通知到。这时候要么引入消息队列广播失效事件，要么放弃本地缓存，直接走Redis哈希结构按需查。
