asyncio.gather并发执行但结果按输入顺序返回，日志等同步操作因不受调度控制而显得乱序；根本原因是事件循环调度协程完成时机与输出顺序分离。
asyncio.gather 并发执行但不控制完成时机
你看到“顺序错乱”，大概率是因为用了 asyncio.gather() 却误以为它会按代码书写顺序依次完成。它只是把所有协程**同时扔给事件循环**，谁先 await 完、I/O 先返回，谁就先结束——但结果列表仍按你传入的顺序排列。这导致日志输出、中间状态打印、甚至某些副作用（比如写文件）看起来“乱序”。
- 常见错误现象：
await asyncio.gather(fetch(1), fetch(2), fetch(3))中，fetch(2)返回最快，但print("done 2")却比fetch(1)的日志还早出现 - 根本原因：每个协程内部的
await点（如await asyncio.sleep(0.1)）决定了让出控制权的时机，事件循环在它们之间快速切换，同步 print 不受调度约束 - 性能影响：总耗时 ≈ 最慢那个协程，但短任务无法“提前释放”资源供其他逻辑使用——它只是快点结束，不代表你能立刻拿到它的副作用结果
await 缺失导致协程对象未执行
写了个 async def 函数，却忘了在调用处加 await，结果返回的是一个 coroutine 对象，不是实际结果。后续逻辑照常往下跑，看似“顺序对”，实则根本没等异步操作，数据为空或类型错误，引发连锁错乱。
- 典型场景：链式调用中漏掉一层
await，比如data = fetch_user(); process(data)—— 这里fetch_user()返回协程，process()拿到的是对象而非字典 - 容易被忽略的地方：函数返回值类型检查弱，IDE 不一定报错；错误可能延迟到下游解包或字段访问时才暴露
- 调试建议：遇到奇怪的
TypeError: 'coroutine' object is not iterable或空数据，第一反应查调用链上有没有漏await
阻塞操作卡死整个事件循环
在 async 函数里调用 time.sleep()、requests.get() 或长循环计算，表面是异步函数，实则阻塞主线程。事件循环停摆，其他所有协程全部冻结，直到该操作结束——这时“顺序”就彻底失控了，所有后续任务都堆在后面等。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 常见错误：用
requests替代aiohttp，或在协程里做大量 CPU 密集型处理（如解析大 JSON、图像缩放） - 正确做法：CPU 密集任务用
loop.run_in_executor()扔进线程池；网络请求必须用异步客户端（aiohttp、httpx.AsyncClient） - 兼容性注意：Python 3.9+ 对阻塞检测更严格，某些环境会警告，但不会自动中断——得靠人盯日志和响应延迟
事件循环嵌套或重复启动
在已运行的 asyncio 环境中又调用 asyncio.run()，或在回调里手动 get_event_loop().run_forever()，会导致 RuntimeError 或静默失效。此时新任务可能被丢弃、旧循环卡住、协程挂起不唤醒——所有顺序都不可信。
立即学习“Python免费学习笔记（深入）”；
- 高频发生场景：Jupyter notebook 里反复运行
asyncio.run(main())；Flask/FastAPI 中错误地在路由函数里启动新 loop；测试时未清理 loop 状态 - 关键判断：报错
RuntimeError: This event loop is already running就是明确信号 - 安全做法：顶层只用一次
asyncio.run()；框架集成时优先用asyncio.create_task()而非手动启 loop；测试用pytest-asyncio管理 fixture
await 之后——那里才是事件循环真正接管的地方。 
