直接在__enter__中创建新连接会破坏连接池复用本意，应从中获取连接并返回可用连接对象，__exit__需安全归还；连接需懒关闭，池应线程安全且避免跨线程误用。
为什么直接在 __enter__ 里创建新连接会破坏连接池本意？
连接池的核心是复用已有连接，而非每次 with 都新建。如果 __enter__ 直接调用 connect()，就退化成普通连接管理器，池子形同虚设。真正该做的，是在 __enter__ 中从池中 get_connection()（或类似方法），并确保该连接在 __exit__ 中被归还而非关闭。
__enter__ 返回什么才符合 with 语义？
必须返回一个可用的数据库连接对象（比如 sqlite3.Connection 或 psycopg2.extensions.connection），而不是池本身。否则用户写 with pool as conn: 时，conn 拿到的是池实例，没法执行 execute()。
- 返回值类型要和你实际想操作的对象一致
- 不能返回
None，否则as后变量为None，运行时报AttributeError - 若池中无可用连接，
__enter__应阻塞等待（如用queue.Queue.get()）或抛出明确异常（如ConnectionPoolExhaustedError），而不是静默失败
如何避免 __exit__ 归还连接时出现“连接已关闭”错误？
常见错误是：用户在 with 块内主动调用了 conn.close()，导致 __exit__ 再次归还时出错。解决方案不是禁止用户调用 close()，而是让连接对象本身“懒关闭”——即重载其 close() 方法，使其实际只标记为可归还，不真正关闭底层 socket。
- 推荐做法：包装原始连接，例如用
WrappedConnection类代理所有方法，在其close()中调用池的return_connection(self._raw_conn) - 不要在
__exit__中无条件调用conn.close()，应判断该连接是否仍处于活跃状态（可通过内部标志位或检查conn.closed属性） - 若发生异常，
__exit__仍需归还连接；但若连接因网络中断已失效，则应丢弃并触发池重建逻辑
使用 threading.local 还是全局队列？
连接池本身应是进程级单例，用线程安全队列（如 queue.Queue）管理空闲连接；而 threading.local 适合存每个线程当前“持有但未归还”的连接引用，用于检测重复归还或跨线程误用。
立即学习“Python免费学习笔记（深入）”；
- 池的
_available_connections必须是共享且线程安全的（queue.Queue天然支持） - 可选地用
threading.local记录_local.current_conn，在__enter__中赋值、__exit__中清空，防止同一连接被两个with块嵌套使用 - 协程场景（async/await）需换用
asyncio.Queue，且__aenter__/__aexit__替代同步版本——这是另一个维度的问题，同步池不可直接用于async with
__enter__ 和 __exit__ 的配合节奏中：前者取，后者还，中间全程不暴露底层连接生命周期控制权。漏掉任一环，就只是个带语法糖的连接工厂。 
