典型现象是Flask应用长时间空闲后首次请求报OperationalError(2013, 'Lost connection...')，本质为MySQL服务端主动断连而SQLAlchemy连接池未感知；须同时配置pool_pre_ping=True（每次取连接前探活）和pool_recycle=3600（设为比wait_timeout小至少10秒）才可靠。
SQLAlchemy连接池自动断开后不重连的典型现象
Flask应用长时间空闲后首次请求报 OperationalError: (MySQLdb._exceptions.OperationalError) (2013, 'Lost connection to MySQL server during query') 或类似 PostgreSQL 的 server closed the connection unexpectedly，本质是数据库服务端主动踢掉了空闲连接，而 SQLAlchemy 连接池没感知、仍尝试复用已失效的连接。
关键配置：pool_recycle 和 pool_pre_ping 必须同时设
pool_recycle 单独设成 3600（1小时）不够——它只控制连接在池中存活时长，不验证连接有效性；真正起作用的是 pool_pre_ping=True，它会在每次从池中取出连接前发一条 SELECT 1 探活。两者配合才可靠：
-
pool_pre_ping=True：强制每次取连接都检测，失败则丢弃并新建，但会轻微增加延迟 -
pool_recycle=3600：避免连接在池里“老死”，尤其对 MySQL 默认 wait_timeout=28800（8小时）但实际常被中间件或云数据库缩得更短的情况 - 不要设
pool_timeout过小（如 1），否则高并发下容易卡住；默认 30 秒通常够用
Flask-SQLAlchemy 中的正确写法（不是直接传 engine_args）
很多人误把参数塞进 SQLALCHEMY_ENGINE_OPTIONS 的 connect_args，这是错的——connect_args 只影响底层 DBAPI 连接建立，不控制连接池行为。必须用 engine_options：
app.config['SQLALCHEMY_ENGINE_OPTIONS'] = {
'pool_pre_ping': True,
'pool_recycle': 3600,
'pool_size': 10,
'max_overflow': 20
}
注意：pool_size 和 max_overflow 要根据实际并发调，盲目放大反而可能压垮数据库。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
MySQL 特别注意：wait_timeout 和 interactive_timeout 不一致会坑人
有些 MySQL 配置里 wait_timeout=60 但 interactive_timeout=28800，而 SQLAlchemy 默认建的是非交互式连接，所以实际受 wait_timeout 约束。查证方式：
- 连上 MySQL 执行
SHOW VARIABLES LIKE '%timeout%'; - 把
pool_recycle设为比wait_timeout小至少 10 秒，比如后者是 60，则设 50 - 云数据库（如阿里云 RDS、AWS RDS）常把
wait_timeout改成 30–60 秒，这点极易被忽略
不看真实数据库配置就硬写 3600，等于白配。
