asyncio.gather()是并发推送首选，需配合aiohttp等异步客户端、Semaphore限流、协程内重试及结构化日志监控，三者缺一不可。
asyncio.gather() 是并发推送的首选，但别直接扔进 loop.run_until_complete()
直接用 asyncio.gather() 并发调用多个通知发送协程，是最常见也最稳妥的方式。它会等待所有任务完成，并按传入顺序返回结果（或抛出第一个异常）。
常见错误是把阻塞式 HTTP 客户端（比如 requests）混进协程里——这会让整个事件循环卡住。必须换用异步客户端，如 aiohttp 或 httpx.AsyncClient。
- 使用
aiohttp.ClientSession()复用连接，避免每请求新建 TCP 连接 - 给每个请求加超时：
timeout=aiohttp.ClientTimeout(total=5)，防止个别通知拖垮整批 - 别在
gather()里传裸await send_sms(...)，要传协程对象：send_sms(...)（不带await）
如何安全控制并发数？别让网关限流打脸
企业通知服务（如短信平台、钉钉机器人、飞书 Webhook）普遍有 QPS 限制。无节制并发可能触发 429 Too Many Requests，甚至 IP 封禁。
用 asyncio.Semaphore 是最轻量、最可控的限流方式，比手动分批 + asyncio.sleep() 更精准。
立即学习“Python免费学习笔记（深入）”；
- 初始化一个信号量：
sem = asyncio.Semaphore(10)表示最多 10 个并发 - 每个发送协程开头加
async with sem:，自动排队获取许可 - 注意：信号量作用域是协程内，不是整个
gather()调用；它管的是“同时发起的请求数”，不是“同时处理的协程数” - 如果通知目标差异大（比如 80% 是企业微信，20% 是邮件），可为不同通道配不同信号量
失败重试不能靠 try/except 包裹整个 gather()
asyncio.gather() 遇到任一协程抛异常，默认就中断并抛出，不会等其他完成。而通知场景需要“尽力送达”——单个失败不该影响其余。
正确做法是在每个发送协程内部做重试，而不是在外层 catch。
- 用
tenacity库的@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10))很省心 - 手写重试时，务必区分异常类型：网络超时（可重试）、400 Bad Request（参数错，重试无意义）、401 Unauthorized（密钥失效，需告警而非重试）
- 重试后仍失败，应记录完整上下文（目标手机号、模板 ID、原始错误信息
str(e)），别只记“发送失败”
企业级日志和监控不能只靠 print()
批量推送一旦上线，你没法盯着终端看输出。必须把关键路径打点进结构化日志，并暴露可观测指标。
- 每条通知发出前打一条 DEBUG 日志，包含唯一 trace_id、target、channel、template_id
- 用
logging.getLogger(__name__)配合 JSON 格式处理器（如python-json-logger），方便 ELK 或 Loki 检索 - 用
aiometer或自定义计数器统计：成功数、失败数、平均耗时、P95 延迟——这些得暴露成 Prometheus metrics，挂到/metrics - 特别注意：别在协程里用
time.sleep()打日志节奏，要用asyncio.sleep()，否则又阻塞 event loop
真正难的不是并发本身，而是怎么让几百个并发请求，在不出错、不被限流、不丢数据的前提下，留下足够线索供你快速定位哪条通知卡在哪一环。信号量、结构化日志、分通道重试策略，这三样缺一不可。
