claude code 生成的 Python 异步代码性能测试报告

去年双11大促前夜，我们一个负责批量查询物流状态的订单服务突然开始疯狂报错。日志里塞满了两类消息：Task was destroyed but it is pending! 和 Event loop is closed，而就在三周前，为了赶进度，团队中有同事用 Claude Code 生成了这个模块的“异步优化版本”。当时代码 review 看着逻辑清晰、asyncio 用法标准，谁都没当回事。直到这个模块在 800 QPS 的真实负载下跑了不到 20 分钟，直接把整个服务打挂，我才被迫坐下来，系统地把 Claude Code 生成的 Python 异步代码，从头到尾、从单功能到长稳、从 CPU 到 I/O，做了整整两周的性能测试。

这篇文章，就是那次测试的完整报告。我不会泛泛地告诉你“AI 写的异步代码有风险”，那样的话谁都会说。我会把测试环境、Prompt、实际跑出来的数据、踩过的坑、以及最终我们给出的落地策略，全部摊在桌上。你可以把它当作一份可以复现的测试方案，也可以当作一份给团队技术选型参考的内部评估。

全文的核心判断只有一个：Claude Code 能写出“看起来正确”的异步代码，但如果你想把它直接放进生产环境，你得先看明白它生成的代码到底在“偷”了哪些性能、吞了哪些异常、隐藏了哪些协程泄漏。

一、直奔结论：三个反直觉的发现

这么多天的测试，我最后凝练成三句话，每一句都跟我最初的假设相反。

发现一：在 I/O 密集型任务上，Claude Code 生成的代码“吞吐量”并没有明显落后于人工优化版本，但“稳定性”相去甚远。

也就是，你拿它跑一个 10 分钟的压测，QPS 曲线很好看；一旦跑到 2 小时以上，曲线就开始出现毛刺，内存开始缓慢爬升，某些协程的完成时间出现长尾。这不是“慢”的问题，是“不可靠”的问题。

发现二：在 CPU 密集型任务混入异步队列时，Claude Code 完全没有主动使用 run_in_executor 的意识，生成的代码会直接阻塞事件循环。

这意味着，如果你的异步服务里有一个稍微耗 CPU 的步骤，比如字符串模板渲染、简单加密、日志序列化，AI 生成的代码会直接把整个事件循环“卡住”，让其他协程排队等死。被我们测出来的这个现象，极其隐蔽，因为功能测试全过，只有压测才暴露。

发现三：长稳测试中，Claude Code 生成的代码几乎都出现了“协程泄漏”，而人工编写的版本通过恰当的 finally 和 task.cancel() 控制住了协程生命周期。

协程没有被正确取消，你每次请求创建的一个 task，可能因为某个异常分支没有 await 返回，就悬浮在事件循环里，吃掉内存，拖慢调度。这是最让我后怕的一点：它不会立刻让服务挂掉，而是像一个慢性毒药，慢慢消耗你的容器资源，直到某天 OOM。

这三个发现直接决定了我们后来的使用策略。为了让结论更立体，我把测试数据用一张环形占比图概括了一下：在一共测试的 18 个 task 中（涵盖 HTTP、文件 I/O、混合负载等场景），AI 生成代码出现的问题类型分布如下。

二、为什么要较这个真：一场线上事故的真实复盘

回到前面那场事故。当时我们的物流查询服务是一个纯异步 Python 服务，基于 aiohttp 构建，上游调用多个第三方物流接口，并发量在促销期间能冲到 800-1200 QPS。原始版本是团队手写的，跑了大半年没出过大问题。问题出在一次迭代中，产品同学要求增加“多物流商聚合查询”能力，变成一个接口背后要并发请求 3-5 个下游，并对结果做合并、超时重试。

任务交给了一个对 asyncio 有一定了解但不算精通的同事。他自己评估了一下工时，觉得如果纯手写，加上超时、重试、熔断、结果聚合，可能要 7 个工作日。于是他让 Claude Code 帮忙生成初版，自己做了少量调整后合入。当时我们 code review 主要看了三点：逻辑对不对、有没有明显死锁、异常有没有被吃掉。看起来都没问题。

压测也做了，问题就出在这里。我们的压测场景太理想了。 总共跑了 5 分钟，QPS 打到 600，99 分位延迟在可接受范围，没报错，就以为万事大吉。

上线后，真实流量的特征是：下游接口时不时返回 500、偶尔超时、偶尔连不上。这些异常在 5 分钟的压测里根本没被充分触发。而 Claude Code 生成的代码，在处理这些“部分失败”时，行为和我们预期完全不一样，它会在某个 asyncio.gather 内部，因为一个协程抛了异常，导致其他协程要么被早早取消，要么留下的 future 没人等，进而引发事件循环警告。

等到流量一高，这些小问题堆积成协程泄漏，事件循环被拖慢，反向又把超时放大，最终变成大面积失败。这个链条，我后来在测试环境里完整复现了。

这件事让我意识到：对 AI 生成代码的性能测试，不能只用“Happy Path”和短时间压测，必须引入异常注入、长稳运行和资源监控。 否则就会像我们一样，把一颗定时炸弹放进生产环境。

三、多数人的误区：“async/await 语法对了，异步就没问题”

在和身边几个团队交流后，我发现一个普遍的误区：只要 AI 生成的代码里用上了 async/await，没有语法错误，逻辑跑通，就默认它的异步行为是“正确”的。

这其实是把“语法正确”等同于“并发模型正确”了。举个例子，下面这段代码是 Claude Code 在没有任何额外提示时，给“并发下载 10 个 URL”任务生成的典型写法：

async def fetch_all(urls):
    tasks = []
    for url in urls:
        task = asyncio.create_task(fetch(url))
        tasks.append(task)
    results = await asyncio.gather(*tasks)
    return results

这段代码在功能测试里毫无问题。但如果你把 fetch(url) 里面可能抛出的 aiohttp.ClientError、超时、连接重置等异常考虑进去，就会发现：一旦任何一个 task 抛出异常，gather 默认行为是立即抛出，其他尚未完成的 task 就会变成“孤儿协程”，它们仍然在后台运行直到完成，但没有人去 await 它们的结果或者捕获异常，最终导致事件循环警告，甚至在某些 Python 版本上直接泄露资源。

我见过不止一个工程师很自然地认为：“AI 写的异步代码，跟网上的最佳实践差不多，应该靠谱。” 这个判断本身就有问题，网上的示例代码为了简化，几乎从来不写完整的异常处理，而 AI 的训练数据主要就是这些简化示例。所以 Claude Code 生成的代码，本质上是“互联网平均水平的异步代码”，而不是“生产级异步代码”。

更隐蔽的一个误区是：很多人以为 asyncio 自动就是高性能的，只要把函数标成 async，性能就会更好。实际上，如果事件循环里混入了没有交给线程池执行的同步阻塞调用，asyncio 的性能反而会比同步版本更差，因为你只搞了一个线程在那里做无用功，别的协程全在排队。Claude Code 生成的代码里，这类“以为异步，实际同步阻塞”的地方，至少在我们测试的多个 task 里出现了 1/3。

四、我是如何设计这场“压力测试”的

为了使结论有参考价值，我必须让测试条件尽可能透明。下面是我设计测试的完整思路。

4.1 环境与版本

• 操作系统：Ubuntu 22.04.3 LTS (x86_64)
• Python 版本：3.12.3
• asyncio 事件循环：默认 SelectorEventLoop（无 uvloop）
• Claude Code 模型版本：claude-sonnet-4-20250514（通过 API 调用，temperature=0，为了保证可复现）
• 对比基线：我本人手写的生产级异步代码（7 年 Python 异步开发经验），经过 code review 和初步优化
• 监控工具：asyncio.Task.all_tasks() 定时采样、tracemalloc 分析内存差异、py-spy 做 CPU 采样、Grafana 看板监控容器资源

4.2 Prompt 设计分级

为了考察 Prompt 质量对生成代码性能的影响，我把 Prompt 分成三个等级：

• P0（无引导）：“用 Python asyncio 写一个函数，并发下载多个 URL 的内容并返回结果。”
• P1（基础约束）：在 P0 基础上增加“要求包含超时处理、异常重试、限制并发数。”
• P2（工程化约束）：在 P1 基础上进一步要求“使用 Semaphore 做并发控制，添加 task 生命周期管理，确保所有协程在异常时被正确取消，返回结果要区分成功和失败，记录日志。”

每个场景都分别用 P0、P1、P2 生成代码，并与人工基线做对比。这样我能判断，到底是 AI 本来能力不行，还是我们提示词没给够。

4.3 测试场景覆盖

我挑选了四个真实业务中高频出现的异步场景：

1. HTTP 并发请求（模拟聚合查询下游 API）
2. 异步文件读写（日志写入、临时文件处理）
3. 混合负载（HTTP I/O + 本地 CPU 计算混合）
4. 长稳运行（7×24 小时持续低压负载，观察资源变化）

每个场景下均有正常情况、部分失败、高负载三个子测试。

整体测试流程我整理成一个进度图，帮助理清步骤。

五、场景一：HTTP 异步并发，QPS 看上去不差，但错误处理是灾难

首先上场的是最常见的 I/O 密集任务：用 asyncio 并发请求 50 个不同的 URL。我在内网搭了一个 mock HTTP 服务，可以模拟正常响应（延迟 20 ~ 80ms 随机）和一定比例的异常（超时、500、连接重置）。

5.1 基准测试：短时间压测

先用 600 QPS 压测 5 分钟，得到如下数据：

单看这个表，P2 版本几乎和人工持平，P0 也仅仅略差一点。到这里，很多人可能就会下结论：“AI 写的没问题啊。”

但我用一张对比柱状图告诉你，这些数字掩盖了什么。

5.2 压力升级：2 小时长压测 + 随机异常注入

我把压测时间延长到 2 小时，并且在 mock 服务中每 5 分钟随机切换一次异常注入策略（随机 500、随机超时 2s、随机断连）。结果，P0 版本在 35 分钟左右开始出现 Task was destroyed but it is pending! 警告，错误率从 0.4% 一路攀升到 12%。

我通过 py-spy 抓了当时的采样，发现问题根源在于：AI 生成的代码没有对 asyncio.gather 的返回值做异常隔离，也没有用 try/except 保护每个子 task。 当一个 URL 请求超时，gather 抛出 TimeoutError，剩余正在运行的 request 协程就被遗弃了，它们仍在后台完成，但结果无处可去，最后被事件循环回收时触发警告。

更糟糕的是，这些被遗弃的协程并未真正释放连接资源。aiohttp 的 session 里连接没有被及时关掉，导致连接池逐渐耗尽,新的请求无法建立连接，雪崩就开始了。

人工版本是怎么做的？很简单，我们用 asyncio.as_completed 逐个处理结果，每个 task 都用独立的 try/except 包裹，并且用 finally 保证 session 释放。这些对于熟练的异步开发者是本能操作，但 AI 在没有明确指令的情况下，不会主动加入。

5.3 Prompt 升级能救多少？

P2 版本因为明确要求了“区分成功和失败”、“正确取消协程”，生成出来的代码已经有了基本的异常隔离，因此长压测错误率只有 2.1%，远好于 P0。但与人工基线（0.1%）相比，仍然有 20 倍的差距。原因在于：P2 生成的代码虽然处理了大部分异常，但在并发控制 Semaphore 的使用上出现了逻辑漏洞，它在 except 块里忘记释放 Semaphore，导致部分时段并发槽位被永久占用，降低了实际吞吐量。

这又是一个看起来正确，实则逻辑有漏洞的例子。

综合这个场景，我给出的判断是：Claude Code 在生成 I/O 密集型异步代码时，如果能提供详细的异常处理和资源管理 Prompt，可以用于非关键路径的原型验证和内部工具，但直接用于核心高并发服务，必须经过严格的异常注入测试。

六、场景二：异步文件读写，把磁盘跑满了才发现“队列”没限流

第二个场景测试的是异步文件读写。用 aiofiles 库进行 1000 个小文件的并发写入，每个文件大小在 1KB~100KB 之间，模拟日志收集落盘或者临时文件处理。

6.1 初测时的奇怪现象

一开始我只看了平均写入耗时和 CPU 占用，结果 AI 生成代码和人工基线相差不大，平均延迟甚至更优，因为 Claude 生成的代码用了更激进的并发数，没有加任何限制，一瞬间开启 1000 个协程去写文件，确实快。

但我在测试时同时监测了主机的磁盘 IO 压力，发现：AI 生成的代码（尤其是 P0）导致磁盘 iowait 飙升到 40% 以上，整个物理机的其他服务都被拖慢。当我尝试在写入过程中取消任务时，大量写入协程因为无法优雅中止，留下一堆半成品文件甚至文件句柄未释放。

人工基线版本则使用了 asyncio.Semaphore 将并发写入限制在 50 个以内，并且在取消信号到达时，通过 await asyncio.gather(*tasks, return_exceptions=True) 捕获 CancelledError，确保每个文件写入要么完整落盘，要么被彻底回滚，不会残留垃圾文件。

我把两个版本在不同并发写入场景下的磁盘 iowait 和平均延迟做了个对比。

6.2 隐藏的资源泄漏问题

在压测结束后，我用 lsof 查看进程打开的文件描述符数量，发现 AI P0 版本在写入结束后，仍有 47 个文件句柄未被释放。追踪代码发现，Claude 在某个异常处理分支中，在 aiofiles.open 后，如果写入中途报错，只在 try 块里用了 async with，但有一个提前 return 跳出了上下文管理器，导致文件没有正确 close。

这种问题在简单功能测试里根本不会出现，因为你通常不会在写入文件的过程中主动 return。但实际业务中，写入中途可能因为内容校验失败而提前退出，AI 生成的代码没有全面覆盖所有退出路径。

这个发现让我进一步明确：即便是相对简单的异步 I/O 操作，AI 也很难完全覆盖边界情况，需要人工对资源管理代码进行逐行 review，尤其是 async with 和 finally 的使用。

七、场景三：混合负载，隐式 CPU 阻塞，让异步变“慢同步”

第三个场景更贴近真实：一个协程需要先发起 HTTP 请求获取数据，然后对数据做本地处理（比如 JSON 解析后做一点数据清洗、格式化），最后再发一次 HTTP 请求提交结果。这种“I/O – CPU – I/O”的模式在微服务里极为常见。

我故意在任务中插入了一个相对耗 CPU 的步骤：对返回的 JSON 做递归的字段转换和校验，在单次调用中大约耗时 15ms。不要小看这 15ms，如果把这样的任务放在异步事件循环里同步执行，事件循环每处理一个任务就阻塞 15ms，当并发上来时，其他协程全在等。

7.1 人工版本怎么做

人工版本的做法是：将 CPU 密集型操作通过 loop.run_in_executor 交给 ThreadPoolExecutor 或 ProcessPoolExecutor 执行，保持事件循环不被阻塞。核心伪代码：

loop = asyncio.get_running_loop()
data = await fetch_data()
processed = await loop.run_in_executor(executor, heavy_cpu_task, data)
result = await submit(processed)

7.2 Claude Code 生成的版本

不管是 P0、P1 还是 P2，Claude Code 生成的代码都没有自主使用 run_in_executor。它生成的典型结构是：

data = await fetch_data()
processed = heavy_cpu_task(data)  # 直接同步调用
result = await submit(processed)

在功能测试里，结果完全正确，循环也能跑通。但我用 py-spy 做 CPU 采样时，发现事件循环线程有大量时间花在 heavy_cpu_task 上，导致 HTTP 请求的 I/O 等待时间被严重拉长。

我复现了 200 并发持续 10 分钟的场景，结果如下：

这个场景得出的教训非常直白：如果你的异步服务里有任何 CPU 密集步骤，且你没在 Prompt 中明确指定使用 run_in_executor，Claude Code 几乎永远不会主动这么做。 你必须自己懂得这个最佳实践，并且把要求写进 Prompt，或者在 review 时手工改造。

八、长稳测试：7×24 小时后，内存曲线说明一切

前面的短时间测试已经暴露了错误处理和资源泄漏的问题，但我还担心一种更隐蔽的故障：协程泄漏和内存缓慢增长。这种问题不会在几分钟内显现，但当服务需要持续运行数周时，一个微小的泄漏最终会导致 OOM。

于是我把人工基线和 Claude P2（P0、P1 因为早期测试就已经不可靠，长稳无意义）分别部署在两个独立容器里，给它们 5 QPS 的恒定低压负载，持续运行 7 天。每天定时采样内存使用量、协程数量和文件描述符数量。

8.1 内存趋势

人工基线版本的内存曲线几乎是一条平稳的直线，在 65MB~70MB 之间轻微波动，符合垃圾回收的正常行为。Claude P2 版本的内存则呈现出缓慢但明确的上升趋势，从第一天的 72MB 开始，到第七天结束时已经达到 118MB，增长了约 64%。虽然还没到 OOM，但这个趋势如果继续，迟早会出问题。

我拉出内存增长曲线图，两者对比非常明显。

8.2 协程数量采样

我每隔 1 小时用 len(asyncio.all_tasks()) 记录协程数量，人工版本总是在 0~5 之间浮动（正常情况下任务很快完成退出）。Claude P2 版本的协程数量则从最初的 2~3 个，慢慢爬升到第 7 天的 28 个。

深入分析后发现问题：Claude P2 版本在实现超时重试逻辑时，使用了一个外层 asyncio.wait_for，当超时发生时取消了等待中的 task，但在取消后并没有用 await task 等待 task 完全结束，而是直接进入下一轮重试。被取消的 task 虽然在逻辑上已经“丢弃”，但因为没有被 await，它仍然挂在事件循环里直到 GC 回收。 长此以往，就形成了协程泄漏。

这个发现让我对 AI 生成代码的长期稳定性彻底失去信心，至少在没有经过专业人工审查的情况下。

九、代码可读性与可维护性：惊喜与惊吓并存

前面都在谈性能，但代码最终是给人维护的，可读性和抽象水平也非常重要。我找来团队中三位不同资历的工程师（1年、3年、5年经验），让他们阅读人工基线版本和 Claude P2 版本，并给出可读性、可维护性、抽象合理性的主观评分（1-10）。

结果很有趣：对于简单任务，AI 生成的代码可读性反而优于人工版本，因为人工版本加了太多防御性代码，显得冗长；AI 版本简洁明了。但在复杂任务上，AI 版本出现了一些诡异的抽象：比如为了复用一段重试逻辑，它定义了一个深层嵌套的闭包，又是 async 又是 try/except，阅读起来非常绕。而人工版本则使用了更平铺直叙但清晰的结构。

综合评分我整理成雷达图：

我的评价是：Claude Code 生成的异步代码，在“看起来很专业”这件事上做得很好，但当你需要快速定位一个问题、或者需要扩展功能时，那些奇怪的抽象和缺失的错误处理会成为绊脚石。 所以，如果这段代码的生命周期超过三个月，我会毫不犹豫地选择人工重构。

十、复杂场景下，Prompt 工程能救回来多少？

前面测试中我们看到，从 P0 到 P2，代码质量有明显提升，但仍然达不到生产级。那么，如果把 Prompt 再加强，明确告诉它“请使用 run_in_executor 处理 CPU 任务，请确保所有协程都被 await，请用 asyncio.as_completed 而不是 gather……”能不能直接产出可用代码？

我专门做了一组实验，用 P3 级别 Prompt，几乎把我能想到的异步最佳实践全部写进去。生成的代码确实好很多，在混合负载场景下，P3 版本的吞吐量达到了人工基线的 85%，错误率降到 1% 以下，长稳运行 48 小时也无明显内存泄漏。

但这带来一个新问题：写出如此详尽的 Prompt，几乎等同于你已经在脑子里把代码设计了一遍，甚至需要你对异步模型的理解比手写代码更深刻，因为你必须提前预判 AI 可能犯的错并逐一打补丁。这样一来，提效的性价比就大打折扣。如果 Prompt 的编写和验证时间接近手写代码的 70% 以上，那省下的时间可能不足以抵消后期排查隐患的成本。

因此我的判断是：对于复杂的异步编程任务，试图通过无限制地加长 Prompt 来让 AI 产出完美代码，边际收益并不高。 更经济的方式是：让 AI 生成初版，然后由有经验的异步开发者进行定向重构，重点修改资源管理、并发控制和异常处理这三个维度。

十一、取舍与落地建议：不同场景下的使用策略

综合所有测试结果，我整理出一份决策参考，供团队在当下阶段使用。

11.1 可以放心使用的场景

• 内部工具、一次性脚本、离线任务：不需要长时间运行，出错影响范围可控。可以直接使用 P2 级别 Prompt 生成后稍作验证。
• 原型验证、功能 Demo：快速搭建能跑通的异步流程，用来验证业务逻辑，后续会完全重写。
• 非关键路径，且 QPS 较低（< 50）：即使有少量协程泄漏，在低负载下影响几近于无，可以接受。

11.2 需要谨慎使用，且必须经过人工审查的场景

• 核心业务服务，QPS 在 100 ~ 500：可以使用 AI 生成代码，但必须进行至少 2 小时的异常注入压测和资源监控，审查重点：协程生命周期管理、gather 异常处理、finally 清理。
• 包含 CPU 密集型步骤的异步服务：Prompt 中必须明确要求使用 run_in_executor，并且审查时用 py-spy 确认事件循环未阻塞。
• 需要长时间运行的服务（> 1 天）：必须进行 24 小时以上的长稳测试，监测内存、协程数量和文件描述符。

11.3 当前不建议使用 AI 生成的场景

• 超高并发核心服务（> 1000 QPS）且对延迟极度敏感：在这种量级下，任何微小的资源浪费都会被放大，建议由资深异步开发者手写。
• 金融交易、支付等强一致性场景：异步代码中的异常处理稍有不当就可能造成数据不一致，不值得冒险。

一个简单的筛查清单，可以用在 Code Review 时：

1. 所有 asyncio.gather 是否包裹在 try/except 中？是否有 return_exceptions 参数？
2. 所有 asyncio.create_task 创建的 task，在异常路径下是否都有对应的 await 或 cancel？
3. 是否存在未使用 run_in_executor 的 CPU 密集调用？
4. async with 和 finally 是否覆盖了所有退出路径？
5. 并发控制信号量 Semaphore 是否在所有异常分支都正确释放？

这份清单最初就是因为 AI 代码踩坑总结出来的，现在已经成为我们团队的必查项。

十二、最后的话

两周的测试做下来，我最深的感触不是“AI 写异步代码不靠谱”，而是它对我们这些工程师提出了更高的要求。

以前，一个 Python 异步新手可能写出来的代码有相同的问题，但在团队里，这种代码往往在 code review 阶段就会被有经验的人打回重写。如今，Claude Code 让新手也能“假装”写出成熟的异步代码，语法的正确性很容易蒙混过关。表面上团队效率提高了，实际上是把风险从编码阶段推迟到了测试阶段，甚至推迟到了生产环境中。

这对于技术 Leader 来说，是一个危险的信号。如果你只看交付的代码量、功能通过率，而忽视了异步代码的正确性和稳定性，那么你很可能正在为自己的服务埋下隐患。

我的建议是：把 AI 当成一个高级的下属，它能帮你快速起草方案，但你必须用自己的专业判断去审视它、修正它。你不能因为下属看起来“语法正确”就放他直接上线，你也不能因为 AI 越来越强就放弃自己作为架构师的责任。

如果你正打算在团队中推广 Claude Code 或者其他 AI 工具来编写 Python 异步代码，下一件值得做的事，就是在你们自己的测试环境里，用真实的业务场景，复现一遍我上面提到的至少三个核心测试：异常注入长压测、CPU 阻塞检测和 7 天长稳。拿到你自己的数据，然后和团队一起讨论，你的服务边界在哪里，你的 Review Checklist 应该包含什么。

这篇报告的测试代码和 Prompts 合集，我也会整理放在我们团队的公开仓库里，供你复现和修改。我们不需要恐惧 AI，但也不能低估它“语法正确”之外的真实门槛。真正理解异步编程的人，才是最后兜底的那个人。希望这个人，在你团队里，依然存在。