Flask-SQLAlchemy开发中何时需要关闭数据库session？

首先明确基础逻辑：你使用db = SQLAlchemy(app)的标准初始化方式时，Flask-SQLAlchemy默认已经绑定了请求级的session自动管理机制，绝大多数场景不需要手动编写关闭逻辑，你遇到的连接异常，大概率是写操作抛异常后没有回滚，导致session残留脏状态。

1. 该场景下应当在什么时机关闭session？ #

分三种场景处理：

• 正常请求流程：完全不需要手动关闭。框架会在请求结束、返回响应前自动执行db.session.remove()，将当前请求绑定的session归还到数据库连接池，等待后续请求复用。
• 写操作异常场景：如果视图中执行了add/delete等写操作，在commit之前抛出了异常，必须在异常捕获块中先调用db.session.rollback()回滚事务，清除session中的脏数据，否则后续请求复用该session时会直接抛出状态异常。
• 请求上下文外场景：如果是在后台异步任务、离线脚本等脱离Flask请求上下文的位置操作数据库，需要在整批数据库操作全部完成后，手动调用db.session.remove()清理session。

异常场景的正确写法参考：

@views.route('/test/', methods=['GET', 'POST'])
def test():
    try:
        db.session.add(something)
        db.session.commit()
    except Exception:
        db.session.rollback()
        return {"code": 500, "msg": "操作失败"}
    return {"code": 200, "msg": "操作成功"}

2. 是否有方案可以在用户离开后自动关闭数据库连接？ #

首先要纠正一个认知偏差：用户离开页面的动作和后端数据库连接释放没有直接绑定关系。
HTTP是无状态协议，后端接收请求、处理完成返回响应后，和客户端的交互就已经结束，不存在“用户离开才触发操作”的时机。
Flask-SQLAlchemy默认的自动清理逻辑，会在当前请求处理完成（哪怕用户中途断开连接）、响应返回前自动将session归还连接池，不需要额外开发。如果你的代码中这套逻辑没有生效，先检查是否是初始化时未正确传入app实例，或是手动修改了session的作用域配置。
如果需要自定义清理逻辑，可以通过teardown_appcontext钩子注册清理函数，该钩子会在应用上下文销毁时必然触发：

@app.teardown_appcontext
def shutdown_session(exception=None):
    db.session.remove()

注意：Flask-SQLAlchemy 1.0及以上版本初始化时已经默认注册了上述钩子，不需要重复添加，只有0.x老版本需要手动配置。

3. 是否需要在每个页面完成数据库操作后就关闭连接？ #

不需要。
首先要明确：调用db.session.remove()本质是把session持有的连接归还到SQLAlchemy连接池，不是和数据库物理断开。连接池会保持固定数量的长连接复用，避免每次请求都新建TCP连接、完成数据库认证带来的性能开销。
正常请求流程中，只需要在请求收尾时由框架统一做一次session清理即可。如果在每个视图的数据库操作后手动关闭，反而会导致同请求后续的数据库操作需要重新创建session、获取连接，徒增性能开销，甚至可能拿到残留脏状态的session引发异常。

4. 每次执行数据库查询后是否需要关闭连接？ #

完全不需要。
SQLAlchemy的session本身实现了工作单元模式和一级缓存，同一次请求中的多次数据库操作本来就应该复用同一个session，才能保证ORM对象状态跟踪正常。如果每次查询完就关闭session，会导致查出来的ORM对象变成脱管状态，后续修改字段、提交更新的逻辑会直接失效。
唯一的例外场景：如果单次请求中执行了超大规模的批量查询，会加载数十万条记录到session内存中，可以在这批查询操作完成后调用db.session.expire_all()清理session缓存，不需要关闭连接。

内容的提问来源于stack exchange，提问作者Max de Boer