空闲连接报 ConnectionResetError 是因数据库服务端主动断连且连接池未及时检测。asyncpg 用 init 参数执行 SELECT 1 验证，配合 max_inactive_connection_lifetime 淘汰旧连接；aiomysql 需禁用 ping 自动重连并手动处理失败；应用退出时必须显式 await pool.close()。
为什么 aiomysql 或 asyncpg 的空闲连接会突然报 ConnectionResetError？
数据库（尤其是 MySQL、PostgreSQL）服务端默认会主动关闭长时间空闲的连接，MySQL 的 wait_timeout 默认是 8 小时，但很多云数据库（如阿里云 RDS、AWS RDS）会设为更短（5–30 分钟）。异步连接池（如 aiomysql.create_pool、asyncpg.create_pool）本身不自动探测连接是否还活着，只在取出连接时直接返回——如果此时连接已被服务端断开，首次执行 conn.fetch() 或 conn.execute() 就会抛出 ConnectionResetError、InterfaceError 或 asyncpg.exceptions.InterfaceError: connection is closed。
这不是你代码写错了，而是连接池“信任”了过期的连接。关键点在于：连接池的 min_size 连接会常驻，但不会自检；而 max_size 之上的连接虽可能被回收，也不保证及时清理失效连接。
如何让 asyncpg 池在取连接前做健康检查？
asyncpg 本身不提供内置的 pre-check 钩子，但可通过 init 参数注入一个协程，在每次从池中取出连接后、交付给业务前执行校验。注意：它不是“取之前”，而是“取之后、用之前”，但效果等价。
- 必须用
await conn.fetchrow('SELECT 1')或await conn.execute('SELECT 1')触发真实网络往返，仅conn.is_closed是不可靠的（状态可能滞后） - 要加
try/except捕获异常，并在失败时显式调用pool._drop_connection(conn)（私有方法，但当前稳定可用）或更稳妥地让连接池自动重试——通过抛出异常并设置max_inactive_connection_lifetime=0 - 推荐组合配置：
max_inactive_connection_lifetime=30.0（单位秒），强制池每 30 秒回收所有空闲超时连接，再配合init做按需验证
示例初始化：
立即学习“Python免费学习笔记（深入）”；
import asyncpg
<p>async def init_connection(conn):
try:
await conn.fetchrow("SELECT 1")
except (asyncpg.exceptions.InterfaceError, ConnectionResetError):
raise # 让 pool 自动丢弃并新建</p><p>pool = await asyncpg.create_pool(
host="db.example.com",
database="mydb",
user="user",
password="pass",
min_size=2,
max_size=10,
max_inactive_connection_lifetime=30.0, # 关键：主动淘汰旧连接
init=init_connection,
)
为什么 aiomysql 的 ping() 不总生效？
aiomysql 的 Connection.ping() 看似是健康检查，但它默认是“静默重连”模式（reconnect=True），即 ping 失败时它会自动尝试重建连接并复位内部状态——这会导致你后续操作仍可能遇到 OperationalError: MySQL server has gone away，因为事务上下文、用户变量、临时表等都丢失了，而你的业务代码并不知道连接已非原连接。
- 务必设
reconnect=False，然后手动处理失败逻辑 - 不要在
create_pool的init中调用ping()：它不是协程，不能 await，且阻塞事件循环 - 正确做法是在每次从池获取连接后、执行业务 SQL 前，显式
await conn.ping()并捕获aiomysql.OperationalError - 若 ping 失败，应
await conn.ensure_closed()，然后continue（重新从池取）或让上层重试
片段示意：
conn = await pool.acquire()
try:
await conn.ping(reconnect=False) # 显式禁用自动重连
except aiomysql.OperationalError:
await conn.ensure_closed()
raise # 触发重试逻辑
# 继续执行 query...
连接池生命周期与应用部署的隐含冲突
Web 应用（如 FastAPI、aiohttp）常把连接池作为全局单例挂载在 app 对象上，但进程重启、热重载（uvicorn --reload）、K8s Pod 重建都会导致旧池未 close 就丢弃。这时残留连接可能卡在 CLOSE_WAIT 状态，服务端等待 FIN 包超时后才释放，期间新池又建连接——最终触发数据库最大连接数限制（Too many connections）。
- 必须在应用退出时显式
await pool.close()，并在finally或 shutdown 事件中调用 - 使用
atexit.register()不可靠（异步资源无法同步清理），应绑定到 ASGI lifespan 或信号处理器（如signal.signal(signal.SIGTERM, ...)） - 云环境尤其要注意：Pod 终止前只有几秒宽限期（如 K8s 默认 30s），
pool.close()默认 timeout 是 60s，需显式传timeout=10
容易被忽略的一点：连接池对象本身不持有引用计数，一旦被垃圾回收，底层连接会立即中断，但服务端未必立刻感知——所以“看似没关”其实是 Python 层已失控，只能靠 max_inactive_connection_lifetime 和主动 close 来兜底。
