一句话定义：事件循环（Event Loop）是一个永不停止的调度循环：它维护着一队待办任务，哪个任务准备好了就执行哪个，执行完立刻回到开头看下一个，全程只用一条主线程。
打个比方：餐厅里只有一位服务员。他给 A 桌点完菜，不会站在厨房门口等出餐，而是转身去招呼 B 桌、C 桌；厨房做好了按铃，他才回去端菜。这位服务员就是那唯一的线程，“按铃”就是回调（callback），“不停环顾四周看谁好了”就是事件循环。他真正消耗时间的地方是传菜，做菜这类真正耗时的活（查数据库、请求第三方接口、读写磁盘）都交给了别人。
为什么单线程能扛很多请求：Web 服务绝大部分时间花在“等”上。如果每个请求开一条线程然后干等，内存和切换成本都很贵。事件循环把“等”注册成回调，交给操作系统（底层常用 epoll、select 这类 I/O 多路复用机制），自己转身处理下一个请求；数据回来了再执行对应回调。所以它擅长 I/O 密集（I/O-bound）场景，单机维持几千个并发连接并不稀奇。Node.js 和 Python 的 asyncio 都是这个套路。
| 事件循环（单线程异步） | 多线程、多进程 | |
|---|---|---|
| 适合的任务 | I/O 密集 | CPU 密集 |
| 切换成本 | 低 | 较高 |
| 主要风险 | 一处阻塞会拖垮全部 | 数据竞争、死锁 |
一行同步代码如何拖垮整个服务：循环只有一条线程，任何一个任务不肯让出执行权，后面所有任务都得排队。比如某个接口里写了段 5 秒的同步计算，或误用了同步 sleep、同步 HTTP 库、同步读大文件，甚至一个回溯爆炸的正则；结果不是这一个接口慢 5 秒，而是这 5 秒里所有请求全卡住，健康检查超时、负载均衡摘掉节点，表面上看起来就像“服务挂了”。原因就在于 CPU 密集（CPU-bound）的代码不会主动让出线程。
Python 还多一层：GIL（全局解释器锁）让多线程跑不出真正的 CPU 并行，所以 CPU 密集任务通常交给多进程或 worker 池，事件循环只负责 I/O 调度。
和相邻概念的区别：事件循环不等于异步编程，它是异步的执行引擎；也不等于 I/O 多路复用，后者是它底层用的系统工具；更不是消息队列那种跨服务中间件。
实际意义：写异步代码的铁律是“别在 async 函数里做同步阻塞调用”，该 await 就 await，拿不准就用压测和事件循环延迟（event loop lag）指标盯着。对普通人来说，手机 App 里一个操作卡住、整个界面转圈，也是同一个道理：UI 的事件循环被堵住了。