Flask本身无内置MVC机制，需开发者主动分层：models不依赖Flask上下文，views仅作协议适配，controller封装业务逻辑并可脱离Web环境运行。
Flask里根本没有内置的MVC分层机制
这是最常被误解的一点：Flask本身是微框架，app.py里写路由+视图+数据库操作完全合法，但不等于“推荐”或“可维护”。所谓“严格MVC”，其实是开发者主动约束——把 models、views、controllers 拆成物理目录+职责边界，而不是靠框架强制。
关键判断标准是：模型类不依赖 Flask 上下文（如 request、session），视图函数只做请求解析与响应包装，业务逻辑全收口到独立的 controller 模块中。
models/ 目录必须脱离 Flask 的 request 和 g 对象
常见错误是模型方法里直接调用 current_user 或读取 g.db，这会让 models 无法在 CLI 命令、后台任务或单元测试中复用。
- 所有数据库操作通过显式传参完成，例如
user = User.get_by_id(db, user_id)，而不是User.get_current() - 避免在
models/__init__.py中导入flask或flask_sqlalchemy；SQLAlchemy 实例应由应用工厂创建并注入 - 外键关系定义用字符串（如
backref="posts"），不要提前引用未初始化的模型类
views.py 只负责 HTTP 协议层的胶水代码
视图函数不是业务入口，而是协议适配器：它解析 request.args、校验 request.json、调用 controller、包装 jsonify 或 render_template。任何 if-else 判断业务状态、拼接 SQL 条件、处理支付回调逻辑，都该移出 views。
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
立即学习“Python免费学习笔记（深入）”；
示例对比：
# ❌ 错误：业务逻辑混在视图里
@app.route('/orders')
def list_orders():
status = request.args.get('status', 'all')
if status == 'paid':
orders = Order.query.filter(Order.paid_at.isnot(None)).all()
else:
orders = Order.query.all()
return render_template('orders.html', orders=orders)
<h1>✅ 正确：只做参数提取和响应包装</h1><p>@app.route('/orders')
def list_orders():
status = request.args.get('status', 'all')
orders = order_controller.list_by_status(status) # 全部交给 controller
return render_template('orders.html', orders=orders)
controller/ 目录要能脱离 Web 环境独立运行
这是检验分层是否干净的关键：把 controller/order.py 拖进 Python shell，手动 import 并调用 list_by_status('paid')，不应抛出 RuntimeError: Working outside of application context。
- controller 函数签名必须显式接收依赖项，如
db、cache、payment_gateway，而非从全局对象获取 - 异常处理集中在 controller 层，统一转为领域异常（如
InsufficientBalanceError），views 再映射为 HTTP 状态码 - 避免在 controller 里调用
url_for或生成完整 HTML 字符串；链接地址由 views 或模板决定
复杂点在于事务边界——比如创建订单+扣库存+发消息，需确保 controller 方法内由调用方控制 db.session.commit() 或使用装饰器封装，否则容易漏提交或重复提交。
