await写在循环里导致串行执行，正确做法是用asyncio.gather并发请求；必须复用ClientSession并设连接池上限；CPU密集操作需用run_in_executor移出协程。
await写在循环里等于变相串行
这是最隐蔽也最常见的性能断点：明明用了aiohttp和async/await，但耗时几乎和requests.get()一样长。问题往往出在把await直接塞进for循环里——每次都要等上一个请求彻底完成才发下一个，事件循环根本没机会调度其他任务。
- 错误写法：
for url in urls: await session.get(url)→ 实际是串行 - 正确做法：先用列表推导式生成所有
Task对象，再await asyncio.gather(*tasks) - 如果必须逐个处理（比如要根据前一个响应决定下一个URL），改用
asyncio.create_task()手动提交，但别await它立刻返回
ClientSession没复用就白搭异步
aiohttp.ClientSession不是“每次请求新建一个”的工具，而是连接池管理器。反复创建ClientSession会导致DNS重查、TCP握手、SSL协商全部重复执行，吞吐量直接打回原形。
- 错误现象：100个请求总耗时40秒以上，
netstat看到大量TIME_WAIT连接 - 必须保证整个生命周期只用一个
ClientSession实例，用async with包裹整个批量请求过程 - 切勿在
fetch函数内部新建ClientSession，那等于给每个请求配独立网线
没设连接池上限反而拖垮自己
不限制并发数的异步爬虫，本质是“自爆式请求”：瞬间发起几千个协程，本地文件描述符耗尽、目标服务器限流、甚至触发防火墙熔断。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 典型报错：
OSError: [Errno 24] Too many open files或ClientOSError: Cannot connect to host - 用
aiohttp.TCPConnector(limit=50)硬性限制最大并发连接数，50是较安全起点 - 配合
ttl_dns_cache=300缓存DNS结果，避免每请求都解析域名 - 若目标网站响应慢，
limit值要往下降（比如20），否则大量协程卡在等待状态，调度开销反超收益
同步操作混进协程会锁死事件循环
哪怕只在async函数里调用一次time.sleep(1)或json.loads()大文本，整个事件循环都会被堵住——其他协程全得排队等它执行完。
立即学习“Python免费学习笔记（深入）”；
- 常见踩坑点：用
BeautifulSoup解析HTML、用json.loads()解大JSON、做正则匹配、甚至print()日志太多 - CPU密集型操作必须移出协程：用
loop.run_in_executor()扔进线程池 - 日志建议用异步日志库（如
aiologger），或至少加flush=True避免缓冲区阻塞
await出现在不该出现的位置，或ClientSession被当成一次性用品，协程就退化成带花哨语法的串行代码。 
