在Go语言中协程（goroutine）被广泛使用，但本文实际聚焦于Python异步编程中一个常见却极易踩坑的核心误区：协程对象本身不可迭代，不能直接放入普通for循环——这不是语法限制，而是执行模型的根本冲突；真正支持“边等待边取值”的是async for配合异步迭代器或async def + yield定义的异步生成器，而试图在列表推导、map或普通for中混用await不仅会触发SyntaxError或TypeError，更暴露了对异步迭代本质的误解：它不是为提速而生，而是为了让“获取下一个值”的过程可挂起、可流式、可内存友好，盲目套用async反而徒增复杂度与开销。

协程不能直接塞进 for 循环里迭代，不是语法报错的问题，而是语义和执行模型根本不匹配。

async for 才是合法的异步迭代入口

普通 for 只能消费同步迭代器（即实现了 __iter__ 和 __next__ 的对象），而协程函数（async def 定义的）返回的是 coroutine 对象，既不是可迭代对象，也不支持 next()。试图这么写：

async def fetch_data():
    await asyncio.sleep(1)
    return [1, 2, 3]
❌ 错误：这不是可迭代对象
for x in fetch_data():  # TypeError: 'coroutine' object is not iterable
print(x)

会立刻抛出 TypeError: 'coroutine' object is not iterable。

真正能配合协程做“逐项等待式遍历”的，只有 async for，但它要求目标必须是**异步迭代器**（实现 __aiter__ 和 __anext__）或**异步生成器**（async def + yield）：

• async for 内部会自动调用 anext() 并 await 其返回值
• 普通 for 完全无视 await，也不会触发 __anext__
• 把协程对象丢给 list()、sum() 等内置函数同样失败

想“边迭代边 await”，得先构造异步迭代器

如果你有一组需要异步获取的值（比如从 API 分页拉数据），不能靠“在 for 里套 await”来实现，因为 for 本身不支持暂停。正确路径是封装成异步迭代器或异步生成器：

async def async_range(n):
    for i in range(n):
        await asyncio.sleep(0.1)  # 模拟异步延迟
        yield i
✅ 正确：async for 驱动异步生成器
async for x in async_range(3):
print(x)

关键点：

• 用 async def + yield 定义的是**异步生成器**，它自动实现异步迭代协议
• 手动实现异步迭代器需显式定义 __aiter__（返回 self）和 __anext__（返回 awaitable）
• 别试图对普通协程函数结果调用 iter()——它返回的仍是 coroutine，不是迭代器

常见误操作：在列表推导或 map 中混用 await

这类写法看着像“迭代中 await”，实则根本跑不通：

# ❌ 全部非法
list(await x for x in coro_list)           # SyntaxError
map(lambda x: await x, coro_list)          # await outside async function
[await x for x in coro_list]               # SyntaxError: invalid syntax

原因很直接：Python 不允许在非协程上下文中使用 await，而列表推导、map、filter 都是同步表达式。可行替代方案只有：

• 用 asyncio.gather(*coro_list) 并发等待全部完成（适合无序、可并行场景）
• 用 async for 配合自定义异步迭代器（适合流式、分页、内存敏感场景）
• 把逻辑包进一个协程，用普通 for 控制流程，内部 await（但这就不是“迭代中 await”，而是“循环体内 await”）

最易被忽略的一点：异步迭代的本质不是“让 for 变快”，而是让“等待下一个值”的过程可挂起。如果没这个需求（比如所有数据已就绪、只是要逐个处理），那就压根不需要协程——强行套 async 反而增加调度开销和理解成本。

以上就是《协程迭代需谨慎，避免并发陷阱》的详细内容，更多关于的资料请关注golang学习网公众号！