finally中connection.close()不生效主因是连接已无效导致close()抛异常，应try/except捕获常见异常；推荐用contextlib.closing或asynccontextmanager确保安全关闭，异步环境需await close()。
为什么finally里的connection.close()有时不生效
不是finally没执行，而是连接对象本身可能已处于无效状态（比如网络断开、服务端主动踢出），调用close()会抛异常，导致后续清理逻辑中断。更隐蔽的是：某些数据库驱动（如psycopg2）的close()是幂等的，但sqlite3在连接已关闭时再调用会抛ProgrammingError。
- 务必在
finally中用try/except包裹close()，捕获AttributeError（对象为None）、ProgrammingError（SQLite）、OperationalError（psycopg2/pg8000）等常见异常 - 不要依赖
connection.closed属性判断——部分驱动该属性更新滞后或不可靠，直接try/except更稳妥 - 若使用连接池（如
SQLAlchemy的Pool），close()实际是归还连接，此时异常概率低，但仍需防护
用contextlib.closing替代手写try/finally
手动写try/finally容易漏掉connection为None的边界情况，而contextlib.closing内部已处理了None和异常安全调用，代码更简洁且不易出错。
from contextlib import closing
import sqlite3
<p>with closing(sqlite3.connect("app.db")) as conn:
cursor = conn.cursor()
cursor.execute("SELECT * FROM users")
print(cursor.fetchall())</p><h1>这里conn自动close()，即使上面raise Exception也保证执行</h1><p>-
closing适用于任何带close()方法的对象，不限于数据库连接 - 注意它不会处理
connect()失败的情况——连接创建失败时with块根本进不去，需在外层捕获 - 若需在
close()后做额外清理（如删临时文件），仍得回退到try/finally
SQLAlchemy中如何避免finally失效
SQLAlchemy 的 Connection 对象在close()后进入“无效”状态，再次调用会报ResourceClosedError；而Engine的dispose()是重置整个连接池，不该在每次请求后调用。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 正确做法：对每个
Connection实例，在finally中调用.close()，并用try/except ResourceClosedError兜底 - 错误做法：在
finally里调用engine.dispose()——这会清空所有空闲连接，严重拖慢并发性能 - 更推荐用
sessionmaker配合contextlib.contextmanager封装，把commit/rollback/close逻辑收口
异步数据库连接（asyncpg、aiomysql）的finally陷阱
异步环境下finally块不能直接await，否则语法报错：SyntaxError: 'await' outside async function。必须确保整个try/finally位于async def函数内，且close()调用前加await。
- 错误写法：
finally: connection.close()——close()是协程，不await等于没调用 - 正确写法：
finally: await connection.close()，且外层函数必须是async def - 若想复用同步风格的资源管理，可用
asynccontextmanager，但要注意其__aexit__内必须await所有异步操作
最易被忽略的一点：连接超时设置（timeout、command_timeout）会影响close()是否阻塞。生产环境务必显式配置，否则网络卡顿时finally可能 hang 住整个线程或协程。
