asyncio.semaphore 应避免重复 await、确保正确释放、按资源类型独立创建、合理设置数量、防止与第三方库限流叠加，并明确各层职责。
asyncio.Semaphore 被重复 await 导致 RuntimeError
多个协程同时 await semaphore.acquire() 是安全的，但常见错误是：在未释放前再次 await semaphore.acquire() —— 这会卡住当前协程，且不报错，只无限等待。更隐蔽的是，在 try/finally 外提前 return 或抛异常，导致 semaphore.release() 永远不执行。
- 永远用
async with semaphore:代替手动acquire()/release()，它自动保证释放 - 不要在
async with块内return或raise后遗漏清理逻辑——async with已处理这点 - 若必须手动管理，确保
release()在finally块中，且仅对已成功acquire()的调用执行
多个 Semaphore 实例混用引发资源竞争
比如为数据库连接、HTTP 客户端、文件写入分别创建 semaphore_db、semaphore_http、semaphore_file，但协程里错误地交叉使用（如用 semaphore_db 控制 HTTP 请求），会导致限流失效或误阻塞。
- 每个资源类型对应独立
asyncio.Semaphore实例，命名体现用途，例如sem_db_write = asyncio.Semaphore(3) - 避免全局共享一个
semaphore管理所有操作——语义不清，扩缩容困难 - 若需组合控制（如“DB + HTTP”并发总数不超过 5”），用
asyncio.BoundedSemaphore并严格文档说明约束条件
信号量数量设置过小或过大带来的实际问题
asyncio.Semaphore(1) 看似“串行化”，但在高并发下反而放大延迟；设为 asyncio.Semaphore(1000) 又可能压垮下游服务，触发 429 或连接池耗尽。
- 数值应基于下游服务能力设定：数据库连接池大小、API 频率限制、磁盘 I/O 吞吐等，而非凭感觉
- 动态调整需谨慎：运行时修改
semaphore._value不安全；应重建新实例并协调协程切换 - 配合超时使用：
async with asyncio.timeout(5): await semaphore.acquire()，防止因信号量长期不可用导致整个任务挂起
与 aiohttp 或 aiomysql 等库的内置限流叠加冲突
比如 aiohttp.ClientSession 默认有连接池限制（connector.limit=100），再套一层 asyncio.Semaphore(10)，实际并发受二者 min(10, 100) 限制，但错误日志里只显示连接超时，看不出是信号量卡住。
- 先关掉第三方库的内置限流（如
aiohttp.TCPConnector(limit=0)），再统一用asyncio.Semaphore控制，职责清晰 - 检查库文档是否已封装信号量逻辑——
aiomysql.create_pool(maxsize=10)本身已是信号量语义，额外加Semaphore(10)属于重复限流 - 用
asyncio.current_task().get_name()打印调试日志，确认阻塞点是在 acquire 还是 socket connect 阶段
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
