为何Python的IsolatedAsyncioTestCase运行速度如此缓慢？
嘿，这个问题问得切中要害！我来帮你拆解一下为什么会出现这么夸张的速度差异~
首先得搞懂IsolatedAsyncioTestCase的核心定位：它的设计目标是为每个异步测试方法提供完全隔离的事件循环环境，这就意味着它要做很多额外的“保障工作”，而这些工作在你手动用asyncio.run()的场景下是完全不存在的。
咱们结合你的测试代码来看：你的f()函数里做了10万次await asyncio.sleep(0)——这其实是在频繁触发任务切换（sleep(0)是用来强制事件循环调度其他任务的常用技巧）。这种高频切换的场景，会把IsolatedAsyncioTestCase的额外开销无限放大，具体来说，慢的原因主要来自这几点：
每次测试都要重建全新的事件循环
IsolatedAsyncioTestCase会为每个异步测试方法单独创建一个全新的事件循环，测试结束后再彻底销毁并清理它。而asyncio.run()虽然也会创建和销毁循环，但它的执行路径非常直接，没有为了“隔离”而附加的校验、跟踪逻辑。为隔离做的额外监控与清理逻辑
为了保证测试之间完全互不干扰，框架会在测试运行前后做很多隐性操作：比如跟踪所有在测试中创建的任务，确保测试结束后没有残留的未完成任务；还会在循环调度时加入钩子，用于监控异步操作的状态。这些步骤单次开销不大，但架不住10万次任务切换的累积，差异一下就拉满了。异步测试的包装逻辑开销
IsolatedAsyncioTestCase会把你的异步测试方法包装成一个特殊的任务来运行，这个包装过程会引入额外的调度层。在你这种高频切换的场景下，每一次await都会多走一层框架的逻辑，10万次下来，时间就差出了好几秒。
从你的测试结果也能直观看到：手动用TestCase加asyncio.run()只需要0.6秒，而用IsolatedAsyncioTestCase要5秒多，这个差距完全是后者为了“绝对隔离”付出的性能代价。如果你的测试不需要严格的隔离（比如多个测试之间不会互相污染事件循环的状态），那用手动触发的方式肯定是更高效的选择。
给你的小建议
- 如果测试场景允许，优先用
TestCase+asyncio.run()的组合，速度优势非常明显； - 如果必须用
IsolatedAsyncioTestCase（比如需要保证测试之间的绝对隔离），可以尽量减少测试中的高频任务切换，比如把多次小的await合并成一次，或者减少循环内的切换次数； - 另外，你也可以关注Python的版本更新，说不定后续版本会对
IsolatedAsyncioTestCase的性能做针对性优化~
备注：内容来源于stack exchange，提问作者Mike
