本文介绍如何在保持发送顺序的前提下，将原本同步阻塞的 `send_to_space()` 调用转为非阻塞异步执行，从而显著提升批量任务吞吐量，同时无需修改原函数、不依赖线程且避免竞态风险。
在实际开发中，我们常遇到这样一类场景：需按严格顺序向外部服务（如 Space API）逐个发送请求，但每个请求本身是 I/O 密集型、耗时数十毫秒，且调用方并不关心响应内容。若直接使用同步循环（for item in items_list: send_to_space(item)），整个流程将被逐次阻塞，总耗时 ≈ N × 单次延迟 —— 这在处理数百项时会明显拖慢整体性能。
此时，asyncio 是最恰当的选择，而非多线程或多进程。原因如下：
- ✅ send_to_space() 是 I/O 等待型函数（即使当前是同步写法），本质适合异步调度；
- ✅ asyncio.create_task() 可立即提交协程并返回 Task 对象，不等待其完成，实现“发完即走”；
- ✅ await 在循环体内逐个 await create_task(…) 保证了逻辑上的严格串行性：前一个请求已发起（非必须完成），才发起下一个，既避免乱序，又消除阻塞；
- ❌ 多线程（Threading.Thread）会引入 GIL 争用与上下文切换开销，且无法天然保障执行/发送顺序；
- ❌ asyncio.gather() 或 asyncio.as_completed() 会导致并发乱序，违背“必须按列表顺序发送”的硬性要求。
以下是优化后的完整实现：
import asyncio # 假设 send_to_space 是一个同步函数（不可修改），例如： # def send_to_space(sub_item): # requests.post("https://api.space.example", json={"data": sub_item}) # 将其包装为可 await 的协程（推荐方式） async def send_to_space_async(sub_item): loop = asyncio.get_running_loop() # 使用 run_in_executor 非阻塞调用同步函数 await loop.run_in_executor(None, send_to_space, sub_item) # 主协程：按序发起请求，不等待响应完成 async def send_items(items_list): for item in items_list: sub_item = item['sub_item'] # 创建任务并立即继续下一轮 —— 发送动作已启动 task = asyncio.create_task(send_to_space_async(sub_item)) # 注意：此处不 await task，否则退化为同步 # 但我们仍需确保“发起顺序”，所以用 await task 确保前一个已提交再发下一个 # 更准确地说：await task 保证前一个请求已进入网络栈，符合“顺序发送”语义 await task # 入口点 if __name__ == "__main__": my_finite_list = [ {"sub_item": "A"}, {"sub_item": "B"}, {"sub_item": "C"} ] asyncio.run(send_items(my_finite_list))⚠️ 关键注意事项：
立即学习“Python免费学习笔记（深入）”；
- 若 send_to_space() 内部含大量 CPU 计算，建议改用 concurrent.futures.ProcessPoolExecutor 替代 None（默认 ThreadPoolExecutor）；
- await task 并非等待响应返回，而是等待该任务被调度并开始执行（在 run_in_executor 场景下，即等待同步函数被线程池接纳）。这已满足“顺序发出”的约束；
- 若你 完全不需要任何等待（甚至不关心是否已成功提交），可改用 asyncio.create_task(…) 后不 await —— 但需额外处理异常和生命周期（如 asyncio.all_tasks() 清理），不推荐用于生产级顺序任务；
- python ≥ 3.9 支持 asyncio.to_thread()（更简洁替代 run_in_executor），可进一步简化包装逻辑。
总结：对于“顺序 + 非阻塞 + 不改原函数”的需求，asyncio 结合 run_in_executor 是兼具简洁性、可控性与可靠性的标准解法。它让同步代码在异步框架中高效复用，是现代 Python I/O 编程的核心实践之一。