Python开发Flask怎么拦截全局请求_使用before_request与装饰器机制-Python教程-PHP中文网

before_request 并非万能：仅对匹配路由的请求生效，不拦截静态文件、未匹配路径及异常处理器内部；需与装饰器分工协作，前者做基础注入，后者做业务约束，并注意 abort() 中断流程。

python开发flask怎么拦截全局请求_使用before_request与装饰器机制

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-parallelization

将顺序 Python 代码转换为并行/并发实现，用于在需要并行化 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
</p>