不用depends实现rbac会更难，因为需手动重复校验角色、无法复用逻辑、难以统一拦截未授权请求，且易导致权限散落、漏判或异常路径失效。
为什么不用 Depends 实现 RBAC 会更难
FastAPI 的 Depends 是权限校验最自然的载体，绕开它意味着你得在路由函数内部手动做角色判断、重复写校验逻辑、无法复用、难以统一拦截未授权请求（比如返回 403 而不是让非法用户进到业务逻辑里）。不使用 Depends 并非技术不可行，而是主动放弃框架提供的生命周期钩子和依赖注入能力，容易导致权限逻辑散落在各处、漏判、或在异常路径下失效。
如何在路由函数内手动校验角色（最小改动方案）
如果你确实因历史约束或临时调试需要跳过 Depends，可在每个 @app.get/@app.post 函数开头显式检查 current_user 的角色字段。前提是已通过其他方式（如中间件、自定义解析器）把用户信息挂到了 request.state 或传入了参数。
- 确保用户对象（例如从 JWT 解析出的
user_data）已存在且含role或scopes字段 - 用
if user_data.get("role") not in ["admin", "editor"]:显式拦截 - 立即返回
JSONResponse(status_code=403, content={"detail": "Insufficient role"})，不要继续执行后续逻辑 - 避免用
raise HTTPException(403)后还写业务代码——控制流易出错
@app.get("/api/posts")
async def list_posts(request: Request):
user = request.state.user # 假设中间件已注入
if not user or user.get("role") != "admin":
return JSONResponse(status_code=403, content={"detail": "Admin only"})
return {"data": [...]}用中间件 + request.state 替代 Depends 的可行性边界
这是“不写 Depends”但又想集中管控的折中做法：在 BaseHTTPMiddleware 中解析认证凭证、加载用户、判断角色，并将结果存入 request.state。但注意——中间件本身无法中断路由执行（除非抛异常或返回响应），且不能像 Depends 那样自动注入参数。
- 中间件适合做「预处理」，不适合做「权限决策后跳过视图」，因为 FastAPI 路由匹配已在中间件之后完成
- 若在中间件里直接
return Response(...)，可拦截，但此时你已失去对路径、方法、预期响应格式的上下文感知 - 更安全的做法仍是：中间件只负责解析并挂载
request.state.user，角色判断仍留在路由内或封装为普通函数调用 - 别试图在中间件里根据 path pattern 做 RBAC 映射——规则会迅速变得不可维护
真正绕不开的复杂点：角色继承、资源级权限、动态 scope
一旦角色不是静态字符串（比如 “admin” > “editor” > “viewer”），或需判断 “用户 A 是否能编辑 ID=123 的文章”，纯函数内联校验就会失控。这时你会发现：Depends 提供的缓存、异步支持、依赖嵌套（如先验身份再查权限）根本没法被手动替代。硬写只会让 if 套 if 深度超过 5 层，且无法单元测试。
所谓“不使用依赖”，往往只是推迟了依赖管理的复杂性——它没消失，只是从声明式挪到了命令式里，藏在了每个函数的前几行。
