事件循环调度是异步执行复杂性的核心，其分阶段轮询机制（如node.js六阶段、浏览器宏/微任务优先级）决定任务顺序，微任务总在当前宏任务结束前清空，且i/o调度依赖底层系统能力，协程失控与调试断裂进一步加剧不确定性。
异步执行流程的复杂性，不在于代码写法本身，而在于事件循环如何调度、协调和响应各类任务。它看似轻量，实则对开发者行为高度敏感——一个同步阻塞调用、一次不当的并发控制、甚至微任务与宏任务的误判，都可能让整个流程偏离预期。
事件循环阶段划分直接影响执行顺序
事件循环不是“统一队列+先进先出”，而是分阶段轮询：在 Node.js 中包括 timers、pending callbacks、idle/prepare、poll、check、close callbacks 六个阶段；浏览器中虽无明确阶段名，但宏任务（如 setTimeout）与微任务（如 Promise.then）存在严格优先级差异。同一段代码在不同环境（Node vs 浏览器）或不同版本中，执行时序可能不同。
- 微任务总是在当前宏任务结束前全部清空，哪怕中间插入多个 Promise 链
- setImmediate 和 setTimeout(fn, 0) 在 Node 中执行顺序受当前 poll 阶段状态影响，非绝对固定
- await 后的语句属于微任务，但其所在函数的后续逻辑仍需等待事件循环下一轮
I/O 调度依赖底层系统能力
事件循环本身不执行 I/O，它依赖运行时绑定的系统级异步机制（如 epoll/kqueue/IOCP）。若程序部署在不匹配的系统上（例如 Linux 上未启用 epoll 的旧版运行时），或容器/虚拟化层屏蔽了高效 I/O 多路复用能力，事件循环会退化为轮询或线程模拟，吞吐量骤降。
- Go 默认使用 epoll（Linux）、kqueue（macOS），无需手动配置
- Python asyncio 在 Windows 上默认用 select 模拟，性能远低于 IOCP，需显式启用 ProactorEventLoop
- Node.js 的 libuv 会自动选择最优后端，但某些嵌入式或精简环境可能缺失对应支持
协程/任务生命周期管理容易失控
协程轻量，不代表可无限创建。每个协程占用栈空间、注册回调、参与调度——当并发数超过文件描述符上限、内存阈值或事件循环处理能力时，延迟上升、OOM 或连接被拒就会出现。这不是“异步慢”，而是资源错配。
- 未加限制的 asyncio.gather(*[fetch(url) for url in urls]) 可能瞬间发起数千 HTTP 请求
- 协程抛出异常未被 await 捕获，会导致 silent fail，且该协程退出后其资源未必及时释放
- 长时间运行的 async for 循环若未主动 await，等同于同步阻塞，卡住事件循环
调试与可观测性天然受限
异步堆栈是断裂的：错误发生在回调中，但调用源头可能在几轮事件循环之前；任务切换无明确上下文快照，传统断点和单步调试难以还原真实执行路径。
- Promise rejection 若未被 catch，仅触发 unhandledrejection 事件，不中断流程也不打印完整链路
- async/await 函数内嵌套过深时，错误堆栈只显示最外层函数，丢失中间 await 点
- 缺乏跨任务追踪 ID（如 trace_id）时，日志分散在不同时间点，难以关联一次用户请求的完整异步路径
