Flask权限系统需自建装饰器并传入资源上下文，因@role_required等静态检查无法应对多租户、运行时依赖等复杂场景；装饰器应支持带参调用、资源解析函数和对象级校验，并区分401/403/404响应。
Flask 本身不提供开箱即用的权限系统，@login_required 只能做登录态拦截，无法区分「普通用户能否编辑某篇文章」「管理员能否删除某个特定资源」这类细粒度场景。真正可行的路径是：自己构造装饰器 + 显式传入资源上下文 + 在装饰器里调用策略判断函数。
为什么不能只靠 @role_required('admin')？
静态角色检查（比如只看用户 role 字段）在真实业务中很快会失效：
- 同一角色在不同资源上权限不同（如「编辑文章」和「编辑用户资料」需分开授权）
- 权限可能依赖运行时数据（如「只能删自己创建的文章」需查
article.author_id） - 租户隔离、组织层级、动态策略（如 RBAC + ABAC 混合）无法靠字符串角色硬编码
所以装饰器必须支持传入参数，并把权限决策逻辑外移到独立函数中，而非写死在装饰器内部。
如何让装饰器接收资源 ID 和操作类型？
关键点是让装饰器支持「带参调用」，且被装饰函数能传递运行时参数给权限校验逻辑：
立即学习“Python免费学习笔记（深入）”；
- 装饰器本身用
functools.wraps包装，接受action和resource_type等策略标识 - 被装饰的视图函数需显式接收资源 ID（如
article_id），并在装饰器内通过*args/**kwargs提取 - 权限校验函数（如
can_user_do(user, action, resource_type, **kwargs)）负责查数据库或缓存，返回布尔值
示例片段：
@app.route('/articles/<int:article_id>', methods=['DELETE'])
@permission_required(action='delete', resource_type='article')
def delete_article(article_id):
# article_id 会被自动传入权限校验函数
...
装饰器里怎么安全提取和验证资源？
直接从 **kwargs 拿 article_id 是危险的——如果 URL 参数名变了，或视图函数签名不一致，就会静默失败：
- 建议在装饰器中约定一个参数名（如
resource_id），并强制视图函数用该名接收 - 或更稳妥地，在装饰器内调用一个「资源解析函数」（如
resolve_article(article_id)），它负责查库、抛异常、返回完整对象 - 权限校验函数应接收这个已加载的对象（而非原始 ID），避免重复查询，也防止绕过校验（如传入伪造 ID 后跳过对象存在性检查）
常见坑：can_user_do(user, 'delete', 'article', article_id=123) 不如 can_user_do(user, 'delete', article=loaded_article) 安全——后者天然包含对象存在性、状态（是否已软删除）、租户归属等校验。
权限拒绝时该返回什么 HTTP 状态码？
别统一用 403 Forbidden ——它掩盖了「未登录」和「已登录但无权」的区别，前端难以区分处理：
- 未登录或 session 失效 →
401 Unauthorized - 已登录但策略拒绝 →
403 Forbidden - 资源不存在或无权访问（如跨租户）→
404 Not Found（避免信息泄露）
装饰器里要先检查认证状态，再走授权逻辑；拒绝时明确抛出对应异常（如自定义 AuthError），由全局错误处理器统一转成响应。
最易被忽略的是权限校验与数据库事务边界的对齐——比如删除前校验有权限，但实际执行时数据已被其他请求修改（如文章已被设为不可删除）。这种竞态需要靠应用层锁或数据库级约束兜底，不是装饰器能解决的。
