redis.asyncio 报 attached to a different loop

第一次 Redis 请求正常，复用异步客户端或连接池后却报 got Future ... attached to a different loop。错误处理过程中还可能跟着出现 Event loop is closed。先把连接打开、请求执行和关闭资源这三个阶段所属的事件循环放在一起看。

连接池可以在同一事件循环中供多个协程复用，不需要为每个并发请求都新建 Redis 连接。问题发生在已建立连接的 reader、writer 被交给另一个循环使用时：TCP 连接由 asyncio.open_connection() 建立，其流对象仍属于创建它的循环。

不只检查客户端创建的位置

模块级创建一个客户端，未必当场打开网络连接。第一个实际请求可能在测试循环 A 建立连接，后续请求又在测试循环 B、应用 lifespan 的循环或 TestClient 的后台 portal 中执行。此时 Python 变量还是同一个，网络资源的所有权却不匹配。

记录客户端与池的实际身份、首次连接所在循环，以及报错请求所在循环。循环标识与测试入口足以帮助比较，不需要记录 Redis URL 中的秘密。多个工作进程也应按各自生命周期建立资源，不把另一个进程或循环的活动连接当成共享配置对象传递。

重复调用 asyncio.run() 包装同一个全局客户端，也会反复创建并结束循环。创建一个新循环再重试，不能把已有的流对象迁移过去。

在资源所属循环内完成创建、使用和关闭

应用应在实际处理请求的生命周期中建立客户端，在该循环内复用，并在循环结束前关闭。以下为生命周期示意，认证与其他连接参数应使用项目已有的受控配置：

import redis.asyncio as redis

async def application_lifetime(redis_url, serve):
    client = redis.Redis.from_url(redis_url)
    try:
        await serve(client)
    finally:
        await client.aclose()

serve 代表应用实际的异步运行入口，并不是一个已有框架 API。结束前要停止接收新工作、等待或取消并处理仍在使用连接的任务，然后才关闭资源；不能关池的同时让请求继续借用它。

若多个客户端显式共享一个外部池，它们仍应处于同一个循环，且明确谁负责最后关闭池。redis-py 当前文档区分内部池、Redis.from_pool() 接管的池与显式共享的池；共享池通常需要在客户端停止使用后单独 await pool.aclose()。不要让一个消费者提前关闭其他消费者仍使用的连接。

测试的 fixture 范围要与应用循环匹配

测试时不能只看 fixture 是 function 还是 session。同步 TestClient 的后台 portal、pytest 异步测试循环和应用 lifespan 可能有不同边界。共享 fixture 范围变大，却仍跨不同的实际循环调用，错误不会自动消失。

按所用框架和测试库的公开生命周期入口创建、注入、使用并关闭资源，确保重复请求处于同一资源所有者的有效范围。为每次请求新建并关闭客户端可以帮助定位复用问题，但不能直接当成高频生产系统的默认设计，也不证明所有 TestClient 错误都属于这一原因。

如果只是 pytest-asyncio 0.25.2 在 teardown 阶段对已关闭循环重复清理，应另看 旧版清理阶段的 Event loop is closed。升级那个补丁不能保证修复运行期间跨循环使用 Redis 连接。

修改后覆盖连续请求、并发请求及应用关闭，确认同一循环内可以正常复用，关闭时没有遗留任务或活动连接。保留原依赖和生命周期配置便于回退；不要捕获全部 RuntimeError 后继续返回成功。