首先，咱们先搞清楚为啥调用了conn.close()还能看到活跃连接——这其实是SQLAlchemy连接池的默认行为在起作用，再加上你代码里的全局变量read_conn加剧了连接管理的混乱。

核心原因 #

• SQLAlchemy连接池的默认机制：当你调用conn.close()时，并不是真的把连接断开并还给数据库，而是把连接放回SQLAlchemy的连接池里，以备后续复用。这是框架默认的优化策略，所以数据库层面依然会显示这些连接是活跃的。
• 全局变量read_conn的风险：用全局变量存储连接对象很容易出问题——比如函数多次被调用时，旧的连接引用可能被覆盖，导致那些旧连接无法被正确归还到连接池，甚至一直占用资源。
• 代码结构的健壮性不足：你的代码里虽然加了try-except，但连接关闭逻辑重复，且零散的异常处理可能导致连接管理失控。

修复后的代码示例 #

咱们改用**上下文管理器（with语句）**自动管理连接，同时去掉全局变量，既能保证连接被正确归还到池，也能让代码更简洁安全：

def get_postgres_data_df(self, table_name):
    result_df = pd.DataFrame()
    if self.debug:
        print('Inside PostgreSQLOperations Class get_postgres_data_df method')
    
    # 用f-string简化连接字符串构造
    connection_string = f'postgresql://{self.user}:{self.password}@{self.host}:{self.port}/{self.database}'
    
    try:
        if self.debug:
            print(f'Trying to read from table {table_name}')
        
        # 创建数据库引擎
        engine = sqlalchemy.create_engine(connection_string)
        
        # with语句自动管理连接：退出块时自动归还连接到连接池
        with engine.connect() as read_conn:
            print(f'Connected to database @ {self.database}')
            if self.debug:
                print(engine.table_names())
            
            query = f'SELECT * FROM {table_name}'
            result_df = pd.read_sql(sql=query, con=read_conn)
            
            if self.debug:
                print(f'Read success for table # {table_name}')
                print(result_df)
    
    except Exception as e:
        print(f'Error during database operation: {e}')
        # 若涉及写操作，可在此添加回滚逻辑
    
    # 若需彻底关闭所有连接（如程序退出前），调用此方法
    # engine.dispose()
    
    return result_df

额外说明 #

• 如果你的场景确实需要彻底断开所有数据库连接（而非放回池），可以在不再需要引擎时调用engine.dispose()，这会关闭连接池里的所有活跃连接。
• 永远避免用全局变量存储连接对象，上下文管理器是Python管理资源（数据库连接、文件句柄等）的最佳实践，能有效避免资源泄漏。
• 构造SQL查询时，尽量使用参数化查询避免SQL注入风险——即使你的table_name是固定的，养成好习惯也很重要。

内容的提问来源于stack exchange，提问作者Local Guide