sqlite3.connect()返回连接对象需手动close()，易致资源泄漏；with语句通过__exit__无条件确保关闭，且需依exc_type区分提交或回滚事务。
sqlite3.connect() 返回的连接对象本身不自动关闭，靠开发者手动调用 close()；一旦遗漏、跳过或中途异常，连接就卡在打开状态——这不是“偶尔出问题”，而是资源泄漏的确定性结果。
<strong>exit</strong> 是连接关闭的最后防线
上下文管理器的 <strong>exit</strong> 方法会在 with 块结束时无条件执行，无论里面是正常返回、return、还是抛出 ValueError、KeyboardInterrupt 甚至 SystemExit。
- 它接收
exc_type参数，可区分是否发生异常：为None时通常该提交事务；非None时应回滚（若业务需要）并确保close()仍被执行 - 不要只关
cursor：游标关闭不等于连接释放，conn.close()才真正归还连接池名额 - 避免在
<strong>exit</strong>里加print()或日志——若此时连接已断开，日志写入可能失败并掩盖原始异常
with 块内不能提前释放连接
常见错误是这样写：
with sqlite3.connect('db.sqlite') as conn:
cursor = conn.cursor()
cursor.execute('INSERT ...')
conn.close() # ⚠️ 错！这里 close 后，with 结束时 __exit__ 还会再调一次 close()
# 后续 conn.execute() 会报 "Cannot operate on a closed database"
- with 的语义是“整个块生命周期由管理器托管”，中间手动 close() 属于越权操作
- 若需提前退出，用 return 或 break 即可，__exit__ 仍会兜底
SQLite 的特殊性：内存连接和 check_same_thread
-
sqlite3.connect(':memory:')创建的连接，即使没close()，Python 垃圾回收也可能清理，但不保证时机，且多线程下极易触发ProgrammingError: SQLite objects created in a thread can only be used in that same thread - 若开启
check_same_thread=False，必须更严格依赖with管理生命周期，否则跨线程使用未关闭连接会导致静默数据错乱
真正容易被忽略的，不是“要不要用 with”，而是 <strong>exit</strong> 中对 exc_type 的判断逻辑是否匹配你的事务语义——提交、回滚、还是无条件关闭，这个分支一旦写反，数据一致性就不可控了。
立即学习“Python免费学习笔记（深入）”；
