@app.route必须放在最外层，因为装饰器执行顺序由外向内，@app.route需注册经@login_required等中间件包裹后的函数，否则鉴权、缓存等逻辑静默失效。
@app.route 必须写在最外层，否则 @login_required、@cache.cached 等中间件类装饰器根本不会执行——这不是 Flask 的 bug，是 Python 装饰器机制本身决定的。
为什么 @app.route 必须放在最外层？
Flask 的 @app.route 本质是调用 add_url_rule()，把函数对象注册进 app.view_functions。它注册的是「最终被调用的那个函数」。
装饰器顺序决定了谁被注册进去：
- 正确顺序：
@app.route('/admin')→@login_required→def admin_view():→ 注册的是经过@login_required包裹后的新函数，请求进来时先走鉴权逻辑 - 错误顺序：
@login_required→@app.route('/admin')→def admin_view():→@app.route拿到的是原始裸函数，@login_required完全没机会运行
Python 装饰器语法糖等价于 admin_view = app.route(...)(login_required(admin_view))，所以外层装饰器必须先“套上壳”，内层才能“注册壳”。
@bp.route 同样受这个规则约束
蓝图里也一样，@user_blueprint.route('/profile') 必须写在 @login_required 上方（即更靠外），否则权限控制静默失效。
立即学习“Python免费学习笔记（深入）”；
常见坑点：
- 模块化项目中，把
@login_required和@bp.route写在同一行或紧挨着，容易误以为顺序没问题 - 多个蓝图混用时，某个蓝图漏了装饰器顺序检查，导致部分路由有鉴权、部分没有
- 使用
app.add_url_rule()手动注册时，传入的view_func必须已是被中间件包裹后的函数，否则同样绕过逻辑
哪些装饰器必须严格守序？哪些可以灵活放？
关键判断标准：该装饰器是否需要在请求分发前介入（读 request、session、抛 abort(403)）。
必须外层的：
-
@app.route/@bp.route -
@login_required（Flask-Login） -
@cache.cached（Flask-Caching） -
@csrf.exempt（Flask-WTF）
位置灵活的：
-
@lru_cache（纯函数级缓存） -
@functools.wraps（仅用于装饰器内部） -
@dataclass或@retry（不改变请求生命周期）
注意：@after_request 是全局钩子，和装饰器顺序无关，但它作用域受限于蓝图注册范围。
错误顺序为什么难排查？
它不报错，服务能启动，路由能访问，页面也能返回内容——只是 @login_required 不拦人、@cache.cached 不生效、CSRF 校验跳过。
最容易被忽略的是：你改了装饰器顺序后，所有测试用例仍通过（因为测试环境常绕过中间件），上线才发现权限失控。
真正要确认是否生效，得看实际请求链路中是否触发了中间件里的日志、abort 或 session 操作——不能只看函数有没有被调用。
