asyncio.Semaphore是协程安全的许可证发放器，精确控制同时执行的协程数量（如Semaphore(3)即最多3个），不干预单次耗时或频率；必须用async with确保自动获取/释放，且需全局共享实例、在请求发起前生效。
asyncio.Semaphore 是什么，它真能控并发数？
asyncio.Semaphore 不是“限速器”，而是“许可证发放器”：它只控制同时能拿到许可（acquire() 成功）的协程数量，不干预单次请求耗时或频率。如果你要限制每秒最多 5 个请求，它做不到——那是 asyncio.sleep() 或令牌桶的事；但你要确保同一时刻最多只有 3 个 aiohttp.ClientSession.get() 在跑，asyncio.Semaphore 就很准。
常见错误现象：RuntimeError: Semaphore.acquire() called on a closed semaphore，通常是因为把同一个 asyncio.Semaphore 实例传给多个事件循环，或在 async with 外提前 close() 了。
- 必须在同一个事件循环内创建和使用，不要跨
asyncio.run()调用复用 - 推荐用
async with semaphore:而非手动acquire()/release()，避免异常导致卡死 - 初始值（如
asyncio.Semaphore(5)）就是最大并发数，不是“最小预留数”
怎么把它塞进 aiohttp 异步请求里？
核心是让每个请求协程在发 HTTP 前先“领号”，拿不到就等别人释放。别直接包住整个 session.get()，而是在其外层加 async with semaphore:。
import asyncio
import aiohttp
<p>sem = asyncio.Semaphore(3) # 同时最多 3 个请求</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill9965" title="macOS UI 自动化技能包 —— 用 Python 控制你的 Mac"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="macOS UI 自动化技能包 —— 用 Python 控制你的 Mac" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill9965" title="macOS UI 自动化技能包 —— 用 Python 控制你的 Mac">macOS UI 自动化技能包 —— 用 Python 控制你的 Mac</a>
<p>让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript
系统要求
macOS 14+ (Sonoma)
Python 3.9+
需要开启：辅助功能 + 屏幕录制权限</p>
</div>
<a href="/xiazai/skill9965" title="macOS UI 自动化技能包 —— 用 Python 控制你的 Mac" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><p><span>立即学习</span>“<a href="https://pan.quark.cn/s/00968c3c2c15" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">Python免费学习笔记（深入）</a>”；</p><p>async def fetch(url):
async with sem: # ✅ 关键：在这里阻塞等待许可
async with aiohttp.ClientSession() as session:
async with session.get(url) as resp:
return await resp.text()</p><h1>错误示范：把 semaphore 放 inside session 或 resp 上下文里，没意义</h1><h1>async with aiohttp.ClientSession() as session:</h1><h1>async with sem: # ❌ 太晚了，session 已建好，起不到限流作用</h1><h1>async with session.get(url) as resp:</h1><h1>...</h1><p>- 如果
ClientSession是复用的（推荐），sem必须在session.get()之前生效 - 不要为每个请求新建
ClientSession，否则sem控制的是“建 session 并发数”，不是“发请求并发数” - 注意
aiohttp默认连接池大小（connector=TCPConnector(limit=100)），它和Semaphore是两层控制：前者管底层 socket，后者管上层逻辑并发
和 requests + threading 对比，为什么不能照搬思路？
同步代码里用 threading.Semaphore 时，你可能习惯在函数入口加 sem.acquire()、出口 sem.release()。但在 asyncio 里，这会出问题：协程可能在 await 时被挂起，release() 没执行，导致许可证永远不归还。
- 绝对不要手写
sem.acquire()+try/finally sem.release()—— 协程挂起后finally不一定执行 -
async with sem:是唯一安全方式，它基于__aenter__/__aexit__，能正确处理await中断 - 别试图在
asyncio.create_task()外围套sem，任务创建不等于执行，真正发请求时才需要锁
实际压测时发现并发数还是超了，哪里漏了？
最常被忽略的是：你可能有多个 asyncio.Semaphore 实例，或者没共享同一个实例。
- 如果每个爬虫类实例都
self.sem = asyncio.Semaphore(5)，那 10 个实例就等于放行 50 并发 —— 必须全局单例或显式传参共享 - 检查是否在
asyncio.gather()里传了未 await 的协程，比如gather(fetch(url1), fetch(url2))没加await，会导致所有协程立刻启动，sem来不及拦截 -
aiohttp的raise_for_status()抛异常后，async with sem:仍会正常退出，这点放心；但自定义异常处理里若吞了异常又没await完上下文，可能破坏语义
复杂点在于：Semaphore 只管“谁有资格开始”，不管“谁先结束”。如果你依赖请求完成顺序做后续动作，得额外用 asyncio.Queue 或 asyncio.Event 协调，别指望它自带调度能力。
