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免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 视图函数不直接操作
session或g，用before_request提前注入 - 错误处理别用
abort(404)到处抛，统一走handle_exception+ 自定义异常类 - API 和页面渲染尽量分离：同一业务逻辑复用，只是响应格式不同（JSON vs HTML）
Controller 逻辑藏在哪？其实就靠蓝图为界
Flask 没有显式的 Controller 概念，但 Blueprint 天然适合做这一层——它隔离路由、加载配置、挂载中间件，还能通过 bp.before_app_request 做全局前置控制。
比如用户模块用 user_bp = Blueprint('user', __name__)，所有和用户相关的权限校验、日志记录、数据预加载，都注册在这个蓝图上，而不是散落在各个 @app.route 里。
- 蓝图的
url_prefix要和业务域对齐，比如/api/v1/users对应api_v1_bp - 不要在蓝图内部 import app 实例，用
current_app或通过create_app工厂传入依赖 - 蓝图间通信别用全局变量，通过
current_app.extensions注册共享服务
templates/static/staticfiles —— 静态资源不是随便扔的
很多人把 JS/CSS 放 static/，模板堆 templates/，就以为 MVC 分层完成了。但真实问题在于：前端组件状态（比如表单校验规则）和后端 Model 验证脱节；JS 里硬编码 API 路径导致重构困难；模板继承层级过深反而降低可读性。
关键不是目录怎么建，而是约定好边界：模板只做展示逻辑，不拼接 URL、不处理时间格式、不判断权限——这些该由视图函数提前计算好传入。
- API 地址统一从
config.py读取，前端用data-api-base属性注入，不写死/api/v1/... - 模板里禁止出现
if user.role == 'admin'，改成视图传入can_delete_post=True -
static/下按功能分包：static/js/modules/、static/css/components/，和后端模块名保持映射
Model 层一旦开始承担 HTTP 状态码生成，View 层开始做数据库事务控制，或者蓝图之间出现循环 import，基本就说明内聚性已经失控了。这时候翻代码比改结构更花时间。
