flask应用关闭时db.close()不生效，因未注册到teardown_appcontext钩子；正确做法是在@app.teardown_appcontext中调用db.session.remove()和db.engine.dispose()，确保覆盖请求、cli及后台任务等所有上下文退出路径。
Flask 应用关闭时 db.close() 不生效？检查是否用了 teardown_appcontext
Flask 的数据库连接泄露，90% 出现在应用退出或请求结束时未正确释放连接。关键不是手动调用 db.close()，而是把清理逻辑注册到 Flask 的上下文生命周期钩子中。直接在 app.run() 后写 db.close() 没用——因为开发模式下 Werkzeug 会 fork 进程，生产环境用 Gunicorn/Uvicorn 更是多进程/协程模型，主进程退出不等于所有连接已释放。
正确做法是使用 teardown_appcontext：它确保每次应用上下文（application context）结束时执行清理，无论请求成功、异常还是 CLI 命令执行完毕。
-
teardown_appcontext是唯一能覆盖所有上下文退出路径的机制（包括flask shell、flask init-db等 CLI 场景） - 不要用
teardown_request—— 它只在请求上下文（request context）结束时触发，而 CLI 或后台任务没有 request - 如果用 SQLAlchemy，优先依赖
engine.dispose()而非手动 close，尤其配合连接池时
SQLAlchemy + Flask 中 engine.dispose() 和 session.remove() 必须成对出现
常见误区是只调用 session.remove() 就以为连接释放了。实际上：session.remove() 清理的是 session 对象本身，但底层连接可能还留在连接池里；engine.dispose() 才真正关闭所有空闲连接并清空连接池缓存。
典型安全写法：
@app.teardown_appcontext
def shutdown_session(exception=None):
if hasattr(db, 'session'):
db.session.remove() # 清理当前上下文绑定的 session 实例
if hasattr(db, 'engine'):
db.engine.dispose() # 关闭连接池中所有空闲连接
- 必须先
session.remove()再engine.dispose()，反过来可能导致活跃 session 试图复用已销毁连接 - 若用
scoped_session，session.remove()是必须的，否则线程/协程间 session 会泄漏 -
engine.dispose()开销略大，别在每次请求结束都调用——只应在应用级退出时用，比如teardown_appcontext
使用 Flask-SQLAlchemy 时，SQLALCHEMY_ENGINE_OPTIONS 中的 "pool_pre_ping" 能防 stale connection，但不能替代显式 dispose
很多人开启 "pool_pre_ping": True 后误以为连接管理“全自动”了。它只是在每次从连接池取连接前做一次简单 ping，失败则丢弃该连接并新建一个——这解决的是数据库主动断连后的自动恢复，不是应用关闭时的资源回收。
-
pool_pre_ping对长连接中断（如 MySQL wait_timeout）有效，但无法防止连接池对象本身驻留内存 - 生产部署时，仍需
teardown_appcontext+engine.dispose()配合，否则 Gunicorn worker 进程退出后连接可能卡在 TIME_WAIT 状态 - 若用异步驱动（如 asyncpg + SQLAlchemy 2.0），
engine.dispose()必须 await，且需注册到异步 teardown 钩子（如app.teardown_async）
Gunicorn 部署时，worker_shutdown 回调比 teardown_appcontext 更早触发，需额外处理
Flask 的 teardown_appcontext 在每个 worker 进程内有效，但它触发时机晚于 Gunicorn 的 worker_shutdown。如果数据库连接依赖全局单例（比如直接 import 的 db），worker 进程收到 SIGTERM 后，Gunicorn 会先执行 worker_shutdown，再让 Flask 处理自己的钩子——此时 Flask 上下文可能已不可用。
- 解决方案：在 Gunicorn 配置中定义
worker_shutdown回调，显式调用db.engine.dispose() - 避免在
worker_shutdown中访问db.session—— 此时 Flask 应用上下文通常已销毁，session可能为 None - 更稳妥的做法是：所有数据库操作封装在函数内，连接通过参数传入，而非依赖全局
db实例，这样可彻底规避上下文生命周期耦合
实际最易被忽略的点是：连接泄露往往不报错，只表现为数据库连接数缓慢上涨、最终拒绝新连接。监控 SHOW PROCESSLIST 或 pg_stat_activity 才能确认是否真有 idle in transaction 或 sleep 状态的残留连接——而不是等应用崩了才查。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
