asyncio.Semaphore 是控制异步任务并发数最直接、轻量且可靠的选择，需用 async with 确保自动释放，避免手动 acquire/release；其他方案如 ThreadPoolExecutor、asyncio.wait() 或 aiojobs 各有适用场景，不可滥用。
asyncio.Semaphore 控制并发数量最直接
想限制同时跑的异步任务数，asyncio.Semaphore 是标准库里最轻量、最可控的选择。它不改写协程逻辑，只在关键入口加一层“闸门”，适合绝大多数 IO 密集型场景（比如并发调用 HTTP 接口、数据库查询）。
常见错误是把 semaphore.acquire() 写成同步调用，或者忘了用 async with 自动释放——漏掉释放会导致后续所有任务永久阻塞。
- 必须用
async with semaphore:包裹临界区，不能手动await semaphore.acquire()+semaphore.release()（容易出错） - 初始化时传入的整数就是最大并发数，比如
asyncio.Semaphore(5)表示最多 5 个任务同时执行 - 如果任务本身可能抛异常，
async with仍能保证释放，比手写 try/finally 更可靠
import asyncio
<p>sem = asyncio.Semaphore(3)</p><p>async def fetch(url):
async with sem: # 这里会自动 acquire/release
await asyncio.sleep(1) # 模拟网络请求
return f"done {url}"</p><p>tasks = [fetch(f"<a href="https://www.php.cn/link/83736f851256ebfd392d677baefc775d">https://www.php.cn/link/83736f851256ebfd392d677baefc775d</a>}") for i in range(10)]
results = await asyncio.gather(*tasks)</p>concurrent.futures.ThreadPoolExecutor 不适合纯 async 场景
有人看到“并发控制”就下意识套用 ThreadPoolExecutor 的 max_workers，但它本质是为同步函数设计的。强行把 await 协程丢进去，会触发 RuntimeWarning: coroutine 'xxx' was never awaited，甚至静默失败。
立即学习“Python免费学习笔记（深入）”；
只有当你明确需要混用同步阻塞代码（比如旧版 requests、PIL 图片处理）且无法改造成 async 版本时，才考虑它——但此时你已不在纯异步路径上，控制目标也变了。
-
asyncio.to_thread()（Python 3.9+）可安全桥接同步函数，配合ThreadPoolExecutor使用，但并发数仍得靠外层Semaphore或asyncio.wait(..., return_when=asyncio.FIRST_COMPLETED)控制 - 不要对
async def函数用loop.run_in_executor()，它不会等待协程完成，只是提交一个未 await 的对象 - 如果你的任务全是
httpx.AsyncClient或aiomysql这类原生 async 库，绕过线程池更干净
asyncio.wait() + limit 参数容易误解
asyncio.wait() 本身没有内置并发数限制参数。网上有些示例用 return_when=asyncio.FIRST_COMPLETED 配合循环调度，看似能控流，但实际逻辑复杂、易漏错误处理，还可能因任务取消导致 wait() 返回空集合而卡死。
它更适合“等一批里的任意一个完成”，而不是“始终保持 N 个运行中”。真要手写调度器，不如直接用 asyncio.Semaphore 简洁。
- 别写
await asyncio.wait(chunk, return_when=asyncio.FIRST_COMPLETED)来模拟限流——chunk 大小 ≠ 并发数，因为任务完成时间不确定 - 如果必须动态调整并发数（比如根据响应延迟升降级），
Semaphore的_value是私有属性，不能直接改；应重建新实例或封装一层带 setter 的 wrapper -
asyncio.as_completed()返回的是完成顺序，也不自带限流，仍需配合Semaphore使用
第三方库如 aiojobs 适合长期后台任务管理
如果你的任务是常驻服务里的后台作业（比如定时清理、消息轮询），aiojobs 提供了 Scheduler 和自动错误日志、优雅关闭等能力，比裸写 Semaphore 更省心。但它不是为一次性批量任务设计的。
典型误用是拿它替代 gather + Semaphore 做短平快的并发请求，反而引入不必要的生命周期管理开销。
- 安装后用
await scheduler.spawn(coro)提交任务，scheduler.limit控制并发上限 - 进程退出前必须
await scheduler.close()，否则可能丢失未完成任务 - 错误默认只 log 不抛出，调试时容易忽略失败任务，建议显式加
try/except或监听scheduler.error
真正难的不是选哪个 API，而是判断“并发数”到底该设多少：它取决于下游服务的承受力、本地事件循环的调度开销、以及任务本身的 IO 耗时波动。设太高可能触发对方限流或本地内存暴涨，设太低又浪费资源——这个阈值得实测，不能只看文档推荐值。
