Flask中Model指用SQLAlchemy等ORM定义的实体类及数据逻辑，应独立于视图和HTTP上下文，集中于models/目录，封装字段、查询与业务校验。Flask 里哪部分算 Model，别硬套 Django 那套Flask 本身不定义 Model 层，SQLAlchemy 或 Peewee 这类 ORM 才真正承载数据逻辑。把数据库操作塞进 views.py 或路由函数里，是新手最常犯的内聚性破坏——看似跑得通，一加个新接口就得复制粘贴一堆 db.session.query(...)。正确做法是把实体定义、基础查询、业务校验全收进 models/ 目录下，比如 User 类里写 def is_active(self)，而不是在视图里反复写 user.status == 'active'。models/__init__.py 只负责统一导出，不放业务逻辑关联查询尽量用 relationship + lazy='selectin'，别在视图里手动 join避免在 Model 里调用 current_app 或 request——它不该感知 HTTP 上下文View 不等于路由函数，更不是模板渲染器Flask 的 @app.route 装饰器只是 URL 绑定入口，真正的 View 层应该封装请求解析、权限检查、响应组装。直接在装饰器函数里写 if request.method == 'POST': ... + render_template(...)，等于把 Controller 和 View 混成一团。推荐把每个业务动作拆成独立函数，放在 views/ 下，比如 auth_views.py 里放 login_view() 和 logout_view()，它们只返回 dict 或自定义响应对象，渲染交给统一的响应包装层。立即学习“Python免费学习笔记（深入）”；视图函数不直接操作 session 或 g，用 before_request 提前注入错误处理别用 abort(404) 到处抛，统一走 handle_exception + 自定义异常类API 和页面渲染尽量分离：同一业务逻辑复用，只是响应格式不同（JSON vs HTML）Controller 逻辑藏在哪？其实就靠蓝图为界Flask 没有显式的 Controller 概念，但 Blueprint 天然适合做这一层——它隔离路由、加载配置、挂载中间件，还能通过 bp.before_app_request 做全局前置控制。 VWO 一个A/B测试工具