Flask before_request 钩子未触发，主因是请求未进入 Flask 生命周期：如被 Nginx/Gunicorn 直接处理、静态路径配置错误、蓝图未正确注册或挂载路径不匹配；钩子对 404/500 仍执行，但 WSGI 层拦截（如 413）则完全不触发。
Flask before_request 钩子没触发，大概率是路由没走 Flask 应用实例
最常见的情况：你写了 @app.before_request，但访问的 URL 实际由 WSGI 服务器（比如 Gunicorn）、反向代理（Nginx）或静态文件服务直接处理了，压根没进 Flask 的请求生命周期。Flask 的钩子只对被 app 实例真正 dispatch 的请求生效。
验证方法：在钩子里加一句 print("before_request fired")，再 curl 一个明确由 Flask 处理的路由（如 /health），看终端有没有输出。如果没输出，说明请求根本没进 Flask。
- 检查是否误把应用挂载在 WSGI 路径子目录下（如
SCRIPT_NAME=/api），而浏览器访问的是根路径 - 确认开发时没用
flask run --static-folder或app.static_folder配置不当，导致静态资源被 Flask 自动响应，绕过视图函数——但注意：before_request对静态文件请求仍会执行，除非你显式禁用了（见下一条） - 如果你用了
app = Flask(__name__, static_folder=None)或app = Flask(__name__, static_url_path='')，又没手动定义静态路由，可能造成部分请求 404 或被 Werkzeug 默认处理器拦截，跳过 Flask 中间件链
before_request 在蓝图中注册却无效？注意作用域范围
蓝图的 before_request 只对注册到该蓝图的路由生效，不是全局的。如果你在蓝图里写 bp.before_request(...)，但视图函数没用 app.register_blueprint(bp, url_prefix='/xxx') 挂载，或者挂载后访问的是其他蓝图/主应用的路由，钩子自然不跑。
另外，多个蓝图注册同名钩子时，执行顺序按注册顺序，但不会叠加——后注册的会覆盖前一个（仅限同一作用域）。主应用的 app.before_request 和蓝图的互不影响，但都必须在对应请求路径上才触发。
立即学习“Python免费学习笔记（深入）”；
- 确保蓝图已正确注册，且目标路由路径匹配
url_prefix - 调试时可在钩子里打印
request.endpoint，确认当前请求是否落入该蓝图管辖范围 - 不要在蓝图里用
@app.before_request（app是全局变量引用，但此时可能未初始化或指向错误实例）
遇到 404 Not Found 或 500 Internal Server Error，before_request 还会执行吗？
会。只要请求进入 Flask 的 WSGI __call__ 流程，before_request 就会在路由解析前运行——哪怕最终找不到视图函数（404），或视图抛出未捕获异常（500），钩子都已执行完毕。
但有两个例外：
- 请求在 WSGI 层就被拒绝（如超大 body 被 Nginx
client_max_body_size拦截，返回 413）→ 完全不进 Flask - 使用了
@app.errorhandler(404)或@app.after_request，但before_request已执行；若想在 404 场景下跳过某些逻辑，得在钩子里主动判断request.endpoint is None
所以如果你发现“某些 404 请求没打日志”，不是钩子失效，而是你可能在钩子里做了依赖 request.endpoint 的操作，而它为 None 导致后续报错中断（但钩子本身已执行）。
调试技巧：用 app.extensions 或简单全局计数器快速验证
别只靠日志埋点。可以在钩子里修改一个模块级变量，再写个测试路由读取它：
hit_count = 0
@app.before_request
def count_requests():
global hit_count
hit_count += 1
@app.route('/debug/hits')
def debug_hits():
return str(hit_count)
这样能排除日志级别、异步写入延迟等干扰。同时注意：
- 多进程部署（如 Gunicorn 多 worker）时，每个进程有独立内存，
hit_count不共享 → 此时应改用 Redis 或文件记录 - 若用 Flask 2.2+，
before_request已标记为 legacy，推荐迁移到app.before_request_funcs字典手动管理，或改用中间件（app.wsgi_app包装） - 钩子函数里抛出异常会直接变成 500，且
after_request不会执行 —— 这是故意设计，不是 bug
真正容易被忽略的是：钩子函数的执行时机在所有装饰器（@app.route、@login_required 等）之前，但它无法修改 request.args 或 request.form 的底层数据结构（它们是不可变的 MultiDict），强行赋值会静默失败。需要改参数，得用 request.environ 或自定义上下文变量。
