before_request 并非万能：仅对匹配路由的请求生效，不拦截静态文件、未匹配路径及异常处理器内部；需与装饰器分工协作，前者做基础注入，后者做业务约束，并注意 abort() 中断流程。
Flask里用 before_request 拦截所有请求，但不是万能的
before_request 确实能拦截进来的每个请求，但它只对当前 Blueprint 或应用实例生效，且**不触发于静态文件、404路由、异常处理器内部**。如果你注册在全局 app 上，它会覆盖所有注册了路由的视图，但不会拦 send_static_file——这是 Flask 内部绕过中间件的优化路径。
常见错误是以为加了 before_request 就能统一鉴权或打日志，结果发现 /static/logo.png 完全没进钩子。这时候得配合 after_request 或单独处理静态资源逻辑。
- 只对匹配到路由（哪怕 404）的请求触发；未匹配路径（如拼错的静态路径）不触发
- 若用了多个
Blueprint，需分别注册，或统一注册到app - 函数内抛出异常会直接跳转到
errorhandler(500)，不会继续执行视图
怎么让 before_request 和装饰器协同工作不冲突
装饰器（比如自定义的 @require_login）和 before_request 都能做前置检查，但职责要分清：前者面向具体视图，后者面向全局上下文。混用时最容易踩的坑是重复校验或状态覆盖——比如 before_request 已把用户对象塞进 g.user，装饰器又去查一遍数据库。
推荐做法是用 before_request 做“基础注入”（如解析 token、设置 g.request_id），用装饰器做“业务约束”（如权限码比对、资源归属校验）。两者顺序固定：before_request 总在装饰器之前运行。
立即学习“Python免费学习笔记（深入）”；
- 避免在
before_request中做耗时操作（如 Redis 查询），否则所有请求都卡住 - 装饰器里别依赖
g的未初始化字段；加if hasattr(g, 'user'):判断更安全 - 若需跳过某类路由（如健康检查接口
/health），在before_request里用request.endpoint或request.path过滤
用装饰器实现细粒度拦截时，functools.wraps 不是可选项
自己写请求拦截装饰器时，如果漏掉 @functools.wraps(func)，会导致 Flask 路由注册失败或调试信息错乱——比如 url_for('view_name') 找不到函数，或者日志里显示的是 decorated_function 而非真实函数名。
这不只是“好看问题”，Flask 内部靠 func.__name__ 和 func.__module__ 绑定 endpoint，装饰后若没保留原属性，app.add_url_rule 可能静默失败。
from functools import wraps <p>def require_role(role): def decorator(f): @wraps(f) # 必须加！ def decorated_function(*args, *<em>kwargs): if not current_user.has_role(role): abort(403) return f(</em>args, **kwargs) return decorated_function return decorator
拦截后想中断请求，别只靠 return，优先用 abort() 或 raise
在 before_request 或装饰器里简单 return 'Forbidden' 是危险的：它会绕过 Flask 的响应处理流程，导致 after_request 不执行、headers 不合并、JSON 自动序列化失效。正确做法是触发标准异常流。
- 用
abort(401)或abort(403)，它们会走 Flask 内置的错误处理链 - 自定义异常需继承
HTTPException，否则errorhandler捕不到 - 若必须返回响应对象，用
make_response()包一层，确保类型是Response实例
容易被忽略的一点：abort() 在 before_request 中调用后，后续钩子（如 teardown_request）仍会执行，但视图函数完全不运行——这点和装饰器里 abort() 行为一致。
