嘿，兄弟们！今天咱们聊聊这件让我花了整整三小时的asyncio大坑。你们一定想：这不是普通的“写个协程跑跑就行”吧？不它是一次彻底踩到深坑的经历，差点把整个服务给卡死，监控弹红灯，连日志dou写满了。

先说背景

我们在Zuo一个实时推理服务。核心流程是：LLM流式推理 → 调用工具 API → 收集结果 → 推理，然后把Zui终输出通过 WebSocket 推给前端。单用户没问题，但当并发达到5人时服务开始周期性卡死。

我本来以为asyncioNeng帮我搞定IO密集型任务，于是直接把所有同步请求改成异步调用。结果…我一把火拼到下午两点，还没搞定就踩进第一个坑——代码根本没有跑并发。

第一个坑：同步阻塞闯进异步世界

我Zui开始用的是这段：

tasks = 
for url in urls:
    task = asyncio.create_task)
    tasks.append
for t in tasks:
    await t

kan起来hen正常，对吧？但 process 内部有个分支直接 return，不抛异常，却让 Task 永远保持 PENDING 状态。geng离谱的是我在 process 的某些分支里用到了 requests.get ——同步阻塞的老古董。

哈哈，我以为 await 就Neng把它变成异步，可实际上事件循环等着第一个 requests.get 返回，其他协程根本没机会跑。

怎么发现的？

日志里每个 task 的耗时dou相同，而且总耗时接近于单个请求时间乘以数量。于是我打开调试器，用 print 检查 call_api_blocking 的实现——原来它就是 requests.get。

那啥啊，你得用 loop.run_in_executor 才行：

async def call_api_async:
    loop = asyncio.get_running_loop
    return await loop.run_in_executor

或者直接改成 aiohttp，这才是真正异步化。

第二个坑：Python 3.12 子解释器与 GIL

Pep684 引入子解释器后我想借助 GIL 隔离来提升并发。但跟 asyncio 搭配太容易出错。有一次我启动了两个子解释器，每个dou加载自己的模块，却因为共享内存导致段错误和引用计数异常。

我当时想：“这不是应该geng安全吗？”但事实是当事件循环跨解释器切换时线程状态会被重置，导致原来的协程无法继续执行。debug 用 gdb+CPython 符号追踪也成了活蹦乱跳的“黑盒”。

第三个坑：Task 泄露 & GC 卡住

aiohttp Session 没关闭、Semaphore 没限制、TaskGroup 没退出——这些小细节dou会让 Task 保持引用，从而导致大块数据永远不被回收。

举例：

async def fetch_one:
    async with self.sem:
        try:
            async with session.get as resp:
                data = await resp.json
                return {"url": url, "status": resp.status, "data": data}
        except Exception as e:
            return {"url": url, "error": str}

解决方案：TaskGroup + Semaphore + 超时控制

下面这段代码是我Zui终用到的核心骨架：

class AsyncFetcher:
    def __init__:
        self.sem = asyncio.Semaphore
        self.timeout = aiohttp.ClientTimeout
    async def fetch_one(self, session: aiohttp.ClientSession,
                       url: str) -> dict:
        async with self.sem:
            try:
                async with session.get(url,
                                       timeout=self.timeout) as resp:
                    data = await resp.json
                    return {"url": url,
                            "status": resp.status,
                            "data": data}
            except Exception as e:
                return {"url": url,
                        "error": str}
    async def fetch_all(self,
                        urls: List) -> List:
        async with aiohttp.ClientSession as session:
            async with asyncio.TaskGroup as tg:
                tasks = 
            # TaskGroup 自动完成
            return 

运行一遍，就从几百秒压缩到几十秒；再加上适当限流，总耗时进一步降低到可接受范围。

常见错误汇总

忘记把同步 I/O 放进 executor；结果事件循环被卡死。

直接在 Flask 路由里写 await；会报 SyntaxError 或 RuntimeError，因为 Flask 本身不是异步框架。

使用多线程或多进程混合 async；GIL 和事件循环冲突，让你抓狂。

没有关闭 aiohttp Session；导致连接泄漏、OOMKilled。

忽略超时设置；网络延迟高峰期就会抛 TimeoutError，整个链路挂掉。

Task 未正确取消；Pending 状态一直存在占内存又不Neng释放。

为什么百度不收录？

说实话，这和技术本身没有关系，但有趣的是有人问过这个问题。我回答：“因为搜索引擎通常只抓取公开可访问的 URL，而我们的 API 是需要鉴权、且只在内部网络可见，所以不会被爬虫抓取。”简短明了你懂吧？Ru果你想让内容被收录，需要确保页面对外可访问，并且放在公共域名下再提交 sitemap 给百度。不过别忘了加上 robots.txt 防止误抓哦！哈哈哈～

"三小时"到底花在哪儿？

PIT-1:    requests 被误认为异步—事件循环卡住

PIT-2:    子解释器导致段错误—排查堆栈指针混乱

PIT-3:    Task Group 没关闭—内存泄漏持续攀升

一下我的经验教训

A. "全家桶必须全家桶": 所有 I/O dou要真正异步化，否则等同于同步等待。别想着半路把阻塞函数塞进去，要么全改成 aiohttp，要么 run_in_executor.

B. "不要跟子解释器玩命": 子解释器虽然理论上隔离，但跟 asyncio 混搭极易出现未知 bug。除非你真的知道自己在干什么否则不要开启它们.

C. "别让 Task 徘徊": 一旦任务返回异常或提前结束，一定要取消未完成的同伴，并清空引用，以免 GC 卡住.

D. "限流才Neng稳定": 超过合理并发量会触发下游限速甚至封 IP，让整个链路失效。用 Semaphore 或者专门库来控制并发数.

E. "超时不可缺位": 网络请求无论多快，dou可Neng因网络拥堵而延迟。这时候设好 ClientTimeout 并捕获 TimeoutError Neng避免链路崩溃.

Zui后一点思考：为什么这件事值得分享？

Mistake makes me better engineer!

The difference between good code and great code is that great code never has hidden bugs waiting to explode when you least expect it.

---