不能在普通 for 循环中直接 await 协程，因为 for 依赖同步的 iter()/next() 协议，而协程需 await 才能执行；应使用 async for（针对异步迭代器）或 asyncio.gather()（并发执行协程）。
不能在普通 for 循环中直接 await 协程，因为 for 本身不支持 awaitable 迭代 —— 它只消费同步迭代器，不是异步迭代器。
为什么 for item in async_iter: 会报错
Python 的 for 语句底层调用的是 iter() 和 next()，这两个都是同步函数。如果你传入一个返回 awaitable 的对象（比如协程函数调用结果、或未被 async for 包裹的异步生成器），for 会尝试对它调用 next()，结果得到一个协程对象而非实际值，接着抛出 TypeError: 'coroutine' object is not iterable 或类似错误。
- 常见错误现象：
TypeError: 'coroutine' object is not iterable、RuntimeWarning: coroutine 'xxx' was never awaited - 典型误写：
for coro in [fetch_data(url) for url in urls]: result = await coro—— 这里fetch_data(url)返回协程，但for并不 await 它 - 真正想做的其实是并发执行多个协程，而不是“迭代协程”，这时该用
asyncio.gather()或asyncio.create_task()
async for 才是合法的异步迭代语法
async for 是 Python 3.6+ 专为异步迭代器设计的语法糖，它要求目标对象实现 __aiter__() 和 __anext__() 方法（即异步迭代器协议）。普通生成器、列表、map 等都不满足这个协议。
- 能用
async for的对象：异步生成器（含async def+yield）、实现了__aiter__/__anext__的类实例 - 不能用
async for的对象：range(10)、[1,2,3]、map(lambda x: x*2, data)、普通def函数返回的生成器 - 示例对比：
async def a_range(n):<br> for i in range(n):<br> await asyncio.sleep(0.1)<br> yield i<br><br>async for x in a_range(3): # ✅ 正确：异步生成器<br> print(x)<br><br>for x in range(3): # ✅ 正确：同步迭代<br> print(x)<br><br>for x in a_range(3): # ❌ 错误：a_range(3) 返回 AsyncGenerator，不可被同步 for 消费
把协程塞进列表再 for 循环，等于放弃并发优势
很多人写 coros = [fetch(url) for url in urls]; for c in coros: await c，这看似“在迭代协程”，实则是串行等待 —— 每个 await 都阻塞后续协程启动，完全失去异步意义。
- 性能影响：总耗时 ≈ 所有请求耗时之和，而非最大值
- 正确做法：
results = await asyncio.gather(*coros)或逐个create_task后await - 兼容性注意：
asyncio.gather在 Python 3.7+ 默认保留顺序；若需取消某任务，应改用asyncio.create_task+asyncio.wait
迭代器和协程的协议根本不兼容
同步迭代器靠 next() 抛 StopIteration 结束；异步迭代器靠 anext() 抛 StopAsyncIteration 结束。两者协议隔离，没有隐式转换机制 —— 就像不能把 int 当 str 直接用，Python 不会帮你自动 await 一个协程来取值。
- 容易踩的坑：以为
list(coroutine_generator)能“展开”协程，结果得到一串未 await 的协程对象列表 - 调试技巧：打印
type(obj)和hasattr(obj, '__aiter__')可快速判断是否为合法异步可迭代对象 - 最常被忽略的一点：即便你写了
async def，如果没用yield，它就只是协程函数，不是异步迭代器；只有含yield的async def才是异步生成器
