SQLAlchemy的create_engine不能全局复用，因MySQL连接可能被服务端超时断开而连接池默认不探测死连接，需启用pool_pre_ping=True和pool_recycle=3600来主动验证与强制重连。
SQLAlchemy 的 create_engine 为什么不能全局复用？
直接在模块顶层调用 create_engine('mysql://...') 并赋值给全局变量，看似省事，实则埋雷。MySQL 连接会因超时（wait_timeout）被服务端主动断开，而 SQLAlchemy 默认的连接池不会主动探测死连接——下次从池里取出这个连接执行 execute() 时，大概率抛出 MySQLdb._exceptions.OperationalError: (2013, 'Lost connection to MySQL server during query')。
正确做法是让引擎感知应用生命周期，并启用连接验证：
- 使用
pool_pre_ping=True：每次从连接池取连接前，先发一个SELECT 1探活，自动剔除失效连接 - 禁用无限连接复用：
pool_recycle=3600（例如 1 小时），强制重连，避免跨过 MySQL 的wait_timeout（默认 8 小时，但常被调低） - 不手动 close() 引擎或连接——交给 Flask-SQLAlchemy 或上下文管理
Flask-SQLAlchemy 的 init_app() 怎么规避应用工厂下的循环导入？
在应用工厂模式中，如果把 db = SQLAlchemy() 和模型定义写在同一文件，容易因导入顺序触发 RuntimeError: application not registered on db instance。核心是分离「实例声明」和「绑定时机」：
- 在
extensions.py中仅声明：db = SQLAlchemy() - 在
app.py或工厂函数内调用db.init_app(app)，此时app已创建且配置就绪 - 模型必须在
init_app()之后导入（例如放在app.py底部，或通过app.register_blueprint()延后加载）
错误示范：from models import User 放在 extensions.py 顶部；正确位置是在 app = create_app() 之后、且 db.init_app(app) 已执行。
请求结束时，SQLAlchemy 会自动清理连接吗？
会，但依赖 Flask 的 teardown_appcontext 钩子，不是魔法。Flask-SQLAlchemy 默认注册了该钩子，在每次请求上下文结束时调用 db.session.remove() —— 这个操作清空线程/协程局部的 session 实例，并将底层连接归还给池，而非关闭。
关键点：
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
-
db.session.remove()不等于db.session.close()：前者解绑 session 对象，后者才真正释放连接（一般不需要手动 close） - 若在异步视图（如
async def）中使用，需确认 Flask 版本 ≥ 2.3 且启用了enable_async=True，否则上下文钩子可能不触发 - 长任务（如 Celery 后台任务）不在 Flask 请求上下文中，必须显式管理：
with app.app_context(): db.session.commit()
如何验证连接是否真的按预期回收？
光看日志不够，得查 MySQL 实时连接数变化。启动 Flask 开发服务器后，执行：
mysql -u root -e "SHOW STATUS LIKE 'Threads_connected';"
然后发起几个请求（比如访问带数据库查询的路由），再立即查一次。如果数值稳定（例如始终是 2–5），说明连接被复用；如果持续上涨（如从 3 → 12 → 25），说明连接没归还，大概率是漏了 db.session.remove() 钩子，或手动调用了 db.engine.dispose() 导致频繁重建连接池。
更直接的方式是加日志：
import logging<br>logging.getLogger('sqlalchemy.engine').setLevel(logging.INFO)
观察日志中是否频繁出现 Connection invalidated 或 Created new connection —— 偶尔有是正常的，高频出现就是配置或生命周期管理出了问题。
最易被忽略的是：开发时用 debug=True 触发重载，会导致应用实例重建但旧引擎未销毁，连接池残留。上线务必关掉 debug 模式。
