SQLAlchemy执行commit()后是否会关闭会话丢失会话参数？

你遇到的commit()后会话级参数丢失，不是SQLAlchemy的必然行为，核心原因是两点：

1. 混淆了SQLAlchemy ORM Session和底层数据库连接的生命周期
   • 你配置的scoped_session确实会持续存在到teardown_appcontext钩子调用remove()才销毁，但这只是ORM层面的会话对象，它不会一直占用底层数据库连接。
   • SQLAlchemy默认逻辑是：事务提交（commit()）或回滚后，当前持有的DBAPI连接会立即归还给连接池，后续有新的数据库操作时再重新从池里取连接。
2. 你使用了NullPool连接池
   • NullPool不会做任何连接复用，连接一旦被归还就会直接销毁，下次取连接时会创建全新的连接，之前通过SET命令设置的PostgreSQL会话级参数自然会全部丢失。
   • 另外你代码中提前执行db_connection = db_engine.connect()创建的连接是冗余的，scoped_session绑定到engine后不会使用这个手动创建的连接。

你目前采用的监听checkout事件重设RLS参数的方案是安全的，属于官方推荐的生产级实践，没有工程风险：

• checkout事件的触发时机是每次底层连接从连接池取出、交付给业务逻辑使用前，不管是新建连接、复用池内连接还是重连后的连接，都会触发该钩子，能100%保证业务逻辑拿到的连接已经配置好正确的RLS参数，不会出现漏设。
• 注意你当前的代码存在两个可优化点：
  • 存在SQL注入风险：不要用f-string拼接SQL语句，改用参数化查询传值。
  • 缺少非请求场景判断：比如离线脚本、定时任务、数据库初始化操作也会从引擎取连接，这些场景下Flask的g对象不存在用户信息，会直接报错，需要加判断跳过。

优化后的事件监听代码参考：

@event.listens_for(db_engine, 'checkout')
def receive_checkout(dbapi_connection, connection_record, connection_proxy):
    # 非请求上下文场景跳过RLS设置
    from flask import has_app_context, g
    if not has_app_context() or not hasattr(g, 'user'):
        return
    cursor = dbapi_connection.cursor()
    # 参数化查询避免注入风险
    cursor.execute("SET app.permitted_workspace_id = %s", (g.user.workspace_id,))
    cursor.close()

• 如果你没有特殊需求，不需要使用NullPool，换成SQLAlchemy默认的QueuePool即可，能大幅减少连接创建销毁的开销，提升性能。不管使用哪种连接池，checkout事件设置RLS参数都是最稳妥的方案，不受连接复用、事务边界、重连等逻辑影响。
• 不要在before_request钩子中设置会话级参数：该钩子中获取的连接可能在commit()后被归还销毁，后续流程拿到新连接时不会再次执行before_request逻辑，这就是你之前偶发权限失效的根本原因。

内容的提问来源于stack exchange，提问作者Nick M