事件循环 on 吾爱主机

Node.js 事件循环与 nextTick / microtask：原理、阶段与工程实践

Thu, 23 Jul 2026 00:00:00 +0800

HTTP 服务偶发“全站卡住几秒”、定时器比预期晚很多、setTimeout(0) 和 setImmediate 顺序飘忽不定、同步校验回调却读到未初始化变量——这些现象往往不是“Node 慢”，而是对 事件循环（Event Loop）阶段、nextTick 队列、微任务队列、Worker Pool 理解不到位。

本文基于 Node.js 官方 Learn 文档 The Node.js Event Loop、Don’t Block the Event Loop，以及 API 文档 process.nextTick / Timers，把调度机制讲清楚，并给出可复现实验与排障清单。

一、问题背景：单线程 JS 为何能扛大量并发

官方对事件循环的定位很直接：

The event loop is what allows Node.js to perform non-blocking I/O operations — despite the fact that a single JavaScript thread is used by default — by offloading operations to the system kernel whenever possible.

也就是说：

应用层 JS 默认跑在一条线程（Event Loop / main thread）。
能丢给内核的非阻塞 I/O（如多数网络 I/O）完成后，内核通知 Node，相关回调进入 poll 等队列等待执行。
不便做成纯非阻塞的昂贵工作（部分 fs、dns.lookup、crypto.pbkdf2、zlib 等）会提交到 libuv 的 Worker Pool，做完再回到事件循环。

Don’t Block the Event Loop 给出的工程拇指法则是：

Node.js is fast when the work associated with each client at any given time is “small”.

线程少、上下文切换少，是 Node 能用较少资源服务大量连接的原因；代价是：任意一次过长的同步回调，都会让其他客户端得不到轮转——既伤吞吐，也构成 DoS 面（恶意大输入、灾难性正则等）。

线程类型	跑什么	阻塞后果
Event Loop	初始化、JS 回调、`await`/`then` 续体、网络等非阻塞 I/O 编排	所有请求排队；定时器/I/O 回调整体延迟
Worker Pool	昂贵任务（多数 `fs`、部分 DNS/Crypto/Zlib、C++ 提交的任务）	池子被占满时同类任务排队；回压到业务

二、核心模型：阶段队列 + 阶段外的 nextTick

1. 启动与相位图

进程启动后会：初始化事件循环 → 执行入口脚本（其中可调异步 API、定时器、process.nextTick()）→ 再进入循环迭代。

官方简化相位（每个 box 是一个 phase）：

 ┌───────────────────────────┐
 │ timers │ setTimeout / setInterval
 └─────────────┬─────────────┘
 v
 ┌───────────────────────────┐
┌─>│ pending callbacks │ 延迟到下一轮的部分系统 I/O 回调
│ └─────────────┬─────────────┘
│ v
│ idle, prepare （内部使用）
│ v
│ poll 取新 I/O 事件；执行 I/O 回调
│ v
│ check setImmediate 回调
│ v
│ close callbacks 如 socket.on('close')
│ v
└───────────── timers ──────────┘

一般规则：进入某 phase 后，先做该 phase 专属操作，再 FIFO 执行队列回调，直到队列耗尽或达到系统相关的上限，再进入下一 phase。

文档还强调：

timers 指定的是“阈值（threshold）之后尽早可执行”，不是精确闹钟；OS 调度与其它回调都会让它推迟。
从 libuv 1.45.0（Node.js 20） 起，每个事件循环迭代中 timers 在 poll 之后运行；为兼容，进入循环前仍会跑一轮 timers。这会影响某些场景下 setImmediate 与定时器的相对时序。
每一轮事件循环之间，若不再等待任何异步 I/O 或定时器，进程可干净退出。

2. 各 phase 在工程上的含义

Phase	主要职责	工程注意
timers	`setTimeout` / `setInterval` 到期回调	阈值语义；可能被长回调推迟
pending callbacks	部分系统操作延迟回调（如某些 TCP `ECONNREFUSED`）	平台差异存在，但日常业务少直接依赖
poll	检索新 I/O；执行几乎所有 I/O 回调（除 close、定时器、`setImmediate`）	空队列时可能阻塞等待；有 `setImmediate` 时可能结束 poll 进入 check
check	`setImmediate`	“poll 完成后立即跑一轮脚本”的专用相位
close callbacks	如 `socket.destroy()` 触发的 `'close'`	否则 close 也可能经 `nextTick` 发出

3. `process.nextTick` 不在相位图里

官方明确：

process.nextTick() is not technically part of the event loop. Instead, the nextTickQueue will be processed after the current operation is completed, regardless of the current phase.

任意 phase 里调用 nextTick，都会在当前操作结束后、事件循环继续前进前排空 nextTick 队列。因此递归 nextTick 可以 饿死 I/O（永远到不了 poll）——这是合法但危险的行为。

process API 进一步说明：

nextTick(callback) 把回调放进 next tick queue；当前 JS 栈操作结束后、事件循环继续前完全排空该队列。
稳定性标注为 Legacy，多数用户代码更推荐 queueMicrotask()。
每次 next tick 队列排空后，会立即再排空 microtask 队列（Promise 的 then/catch/finally、queueMicrotask）。
模块系统差异（官方示例）：
- CJS：通常 nextTick → Promise/queueMicrotask
- ESM：模块求值本身已在 microtask 路径上，常见顺序是 Promise/queueMicrotask → nextTick

// CJS 常见输出：nextTick → resolve → microtask
const { nextTick } = require('node:process');
Promise.resolve().then(() => console.log('resolve'));
queueMicrotask(() => console.log('microtask'));
nextTick(() => console.log('nextTick'));

// ESM 常见输出：resolve → microtask → nextTick
import { nextTick } from 'node:process';
Promise.resolve().then(() => console.log('resolve'));
queueMicrotask(() => console.log('microtask'));
nextTick(() => console.log('nextTick'));

4. `setImmediate` vs `setTimeout(0)`

API	语义（官方）	典型落点
`setImmediate(fn)`	poll 阶段结束后执行脚本	check phase
`setTimeout(fn, 0)`	至少等待阈值（0ms）后尽早执行	timers phase

主模块顶层同时调度两者：顺序不确定，取决于进程性能与调度。
在 I/O 回调内（例如 fs.readFile 回调里）同时调度：官方保证 setImmediate 总是先于 timers，与 timers 数量无关。

官方也坦言命名历史包袱：nextTick 比 setImmediate 更“立即”，名字几乎应互换；但为兼容 npm 生态不会改名。一般推荐优先用 setImmediate 推理成本更低；nextTick 留给“必须在调用栈展开后、循环前进前”的场景。

三、实践：可复现实验

实验 A：I/O 周期内 immediate 恒先于 timeout(0)

// save as io-order.js (CJS)
const fs = require('node:fs');

fs.readFile(__filename, () => {
 setTimeout(() => console.log('timeout'), 0);
 setImmediate(() => console.log('immediate'));
});

node io-order.js
# 期望：
# immediate
# timeout

实验 B：nextTick 在“当前操作后”插入，早于进入下一 phase

// nexttick-vs-immediate.js
const fs = require('node:fs');

fs.readFile(__filename, () => {
 setImmediate(() => console.log('immediate'));
 process.nextTick(() => console.log('nextTick'));
 Promise.resolve().then(() => console.log('promise'));
});

在 I/O 回调这个“当前操作”末尾，会先排空 nextTick，再处理 microtask，然后事件循环才能推进到后续 phase（check 中的 immediate）。你应看到 nextTick 先于 immediate；CJS 下 nextTick 通常也先于 promise。

实验 C：为何 API 必须“全同步或全异步”

官方反例：签名像异步、实际同步调用回调，调用方无法判断后续语句与回调的先后：

// BAD：可能同步也可能异步
function maybeSync(arg, cb) {
 if (arg) {
 cb();
 return;
 }
 require('node:fs').stat('file', cb);
}

推荐：同步路径也 nextTick(cb)（或统一走 Promise），保证“总是异步”：

const { nextTick } = require('node:process');
const fs = require('node:fs');

function definitelyAsync(arg, cb) {
 if (arg) {
 nextTick(cb);
 return;
 }
 fs.stat('file', cb);
}

构造函数里 emit 同理：应 nextTick(() => this.emit('event'))，让调用方先挂上监听器。

实验 D：同步计算堵死循环（对照）

// block-loop.js
const http = require('node:http');

http.createServer((req, res) => {
 if (req.url.startsWith('/block')) {
 const end = Date.now() + 3000;
 while (Date.now() < end) {} // 同步忙等 3s
 res.end('blocked\n');
 return;
 }
 res.end('ok\n');
}).listen(3456, () => console.log('listen 3456'));

开两个终端：

# 终端 1：触发阻塞
curl -sS http://127.0.0.1:3456/block &
# 终端 2：立即请求轻量路径
time curl -sS http://127.0.0.1:3456/

会观察到轻量请求也被拖慢——因为 Event Loop 被同一线程的同步代码占满。

四、常见坑与排查

现象	可能机制	处理方向
全站偶发卡顿、延迟尖刺	同步 CPU 重活 / 大 JSON / 灾难正则 / 长循环	限制输入；分区 yield；`worker_threads` / 子进程卸载
`setTimeout(100)` 变成 105ms+	poll 长回调占住队列；阈值语义 + 其它回调	缩短 poll 回调；避免在 I/O 回调里做重计算
顶层 `setTimeout(0)` 与 `setImmediate` 顺序随机	主模块非 I/O 周期，时序依赖性能	需要稳定顺序时放到 I/O 回调，或只用一种调度 API
递归 `nextTick` 后 I/O 永不完成	nextTick 队列饿死 poll	改 `setImmediate` / 批处理 + yield
CJS/ESM 下 Promise 与 nextTick 顺序不一致	官方文档写明的队列次序差异	不要依赖跨模块类型的微次序；业务用明确的 async 编排
`fs`/`crypto` 变慢但 CPU 不高	Worker Pool 打满	评估 `UV_THREADPOOL_SIZE`、减少同步 `*Sync`、合并小 I/O
同步 API 伪装异步	调用方竞态	统一异步边界；错误路径也 `nextTick`/`queueMicrotask`

不要阻塞 Event Loop 的检查清单（摘自官方思路）：

每个回调的计算复杂度是否随用户输入线性/超线性膨胀？是否有上限校验？
是否存在嵌套量词正则（REDOS）？简单包含用 indexOf/includes。
大对象是否在主线程 JSON.parse / stringify？能否限制体积或卸载到 Worker？
是否误用 *Sync 文件/加密 API 于请求路径？
需要“下一轮再继续”时，默认优先 setImmediate / queueMicrotask，慎用无限 nextTick。

分区（Partitioning）示例思路：把 O(n) 求和拆成多步，每步 O(1)，用 setImmediate/queueMicrotask 让出循环，避免单次回调霸占主线程。更重的任务则应 Offloading 到 Worker（worker_threads、独立进程或 C++/N-API 任务），而不是只靠在主循环里切片。

五、总结

Node 的并发模型是 单线程 Event Loop + libuv Worker Pool：I/O 与任务要“碎、短、可让出”。
相位队列决定 timers / poll / check / close 等回调归属；nextTick 与 microtask 是阶段之间的优先通道。
I/O 回调内 setImmediate 稳定早于 setTimeout(0)；主模块顶层两者顺序不稳定。
nextTick 适合“栈展开后、循环前进前”的 API 契约；滥用会饿死 I/O。新代码多数场景优先 queueMicrotask / setImmediate。
性能与安全同一条线：限制输入、避免 REDOS、大 JSON 与 CPU 重活卸载，才能让“少线程高并发”真正成立。

把调度图画进团队约定后，再写中间件、ORM 钩子、连接池回调，会少掉一大类“玄学时序 bug”。

参考资料

The Node.js Event Loop — Node.js Learn（阶段图、poll/check/timers、setImmediate vs setTimeout、process.nextTick）
Don’t Block the Event Loop (or the Worker Pool) — Node.js Learn（Event Loop vs Worker Pool、阻塞危害、分区/卸载、REDOS/JSON）
Understanding process.nextTick() — Node.js Learn
process.nextTick / queueMicrotask 对比 — Node.js API（CJS/ESM 次序、Legacy 说明）
Timers — Node.js API（setImmediate / setTimeout、ref/unref）
源码文档镜像：nodejs/node doc/api/process.md、doc/api/timers.md

Python asyncio 事件循环与 Task 取消：原理、API 与工程实践

Mon, 20 Jul 2026 00:00:00 +0800

高并发 HTTP 客户端、WebSocket 网关、爬虫调度、微服务侧车——Python 侧大量 IO 密集型场景会落到 asyncio。写得不好时，常见症状是：协程“创建了却从不调度”、后台 Task 被 GC 悄悄干掉、超时后资源不释放、CancelledError 被误吞导致 TaskGroup / timeout 行为异常。

本文基于官方文档 asyncio — Asynchronous I/O、Coroutines and Tasks、Runners、Developing with asyncio，以及 PEP 492，把 事件循环协作调度、Task 生命周期、结构化并发、取消与超时 讲清楚，并给出可复现的写法与排障清单。

一、问题背景：并发不等于多线程

asyncio 的定位很明确：

asyncio is a library to write concurrent code using the async/await syntax.
asyncio is often a perfect fit for IO-bound and high-level structured network code.

它解决的是“大量等待网络/磁盘时如何让 CPU 去干别的活”，而不是用多核并行跑 CPU 密集计算。事件循环通常跑在 一个线程 内：某个 Task 在执行同步代码时，同线程的其他 Task 无法推进；只有执行到 await，当前 Task 挂起，循环才调度下一个。

若把 time.sleep、同步 requests、重型 JSON/CPU 计算直接塞进协程，等价于堵死整条事件循环。官方开发指南的原则是：阻塞工作放到线程池（asyncio.to_thread / loop.run_in_executor），循环线程只做非阻塞 IO 与调度。

概念	含义	工程后果
协程函数 `async def`	调用后得到协程对象，不会自动运行	只写 `foo()` 而不 `await`/`create_task` 会 RuntimeWarning
Awaitable	可被 `await` 的对象	三类主路径：协程、Task、Future
Event loop	调度 Task/回调、做网络 IO、跑子进程	应用层优先用 `asyncio.run`，少直接操作 loop
Task	被调度执行的协程包装	可取消、可聚合、可命名/追踪

二、核心模型：协作式调度 + 弱引用 Task

1. 必须“跑起来”，而不能只“创建”

import asyncio

async def main():
 print("hello")
 await asyncio.sleep(1)
 print("world")

asyncio.run(main())

官方示例同时强调反例：

>>> main()
<coroutine object main at 0x...>

单纯调用协程不会把它排进事件循环。入口应使用 asyncio.run(coro)：它负责创建/关闭循环、收尾异步生成器、关闭默认 executor。同一线程已有运行中的 loop 时不能再调用 asyncio.run（嵌套场景用 asyncio.Runner 或上层框架提供的生命周期）。

2. 并发来自 Task，不是“多写几个 await”

串行：

await say_after(1, "hello")
await say_after(2, "world") # 总耗时约 3s

并发：

task1 = asyncio.create_task(say_after(1, "hello"))
task2 = asyncio.create_task(say_after(2, "world"))
await task1
await task2 # 总耗时约 2s

create_task 把协程包成 Task 并立即调度。一个极易踩坑的细节（官方明确写出）：

The event loop only keeps weak references to tasks. A task that isn’t referenced elsewhere may get garbage collected at any time, even before it’s done.

“发后不管”的后台任务必须放进集合，并在 done 回调里移除：

background_tasks: set[asyncio.Task] = set()

def spawn(coro):
 task = asyncio.create_task(coro)
 background_tasks.add(task)
 task.add_done_callback(background_tasks.discard)
 return task

3. 结构化并发：优先 `TaskGroup`（3.11+）

asyncio.TaskGroup 把“创建 + 等待全部结束”绑在异步上下文管理器里：

async def main():
 async with asyncio.TaskGroup() as tg:
 tg.create_task(say_after(1, "hello"))
 tg.create_task(say_after(2, "world"))
 # 退出 with 时，组内任务均已结束

组内若有任务抛出非 CancelledError 的异常，会汇总为 ExceptionGroup / BaseExceptionGroup 再抛出。相对“手写 create_task + 忘记 await”，TaskGroup 更不容易留下孤儿任务。

API	典型用途	注意点
`create_task`	灵活并发、需要 Task 句柄	保持强引用；自行处理汇合
`TaskGroup`	结构化并发、统一收口	异常变为 ExceptionGroup；依赖取消语义正确
`gather(*aws, return_exceptions=False)`	固定一批 awaitable 一起等	默认某任务异常会影响整体策略；结果顺序与入参一致
`wait(aws, return_when=...)`	需要 `done/pending` 集合或 FIRST_COMPLETED	入参必须是 Future/Task 集合，不能是裸协程习惯用法

gather 适合“固定 N 路、要按入参顺序拿结果”：

results = await asyncio.gather(
 fetch(u1),
 fetch(u2),
 fetch(u3),
 return_exceptions=True, # 单个失败不中断其余；结果里可能是 Exception 实例
)

return_exceptions=False（默认）时，任一 awaitable 以异常结束，gather 会把该异常传播给调用方（其余任务的收尾策略仍需按版本与场景理解，工程上更稳妥的是用 TaskGroup 明确“有错就结构化失败”）。wait 则返回 (done, pending)，并可用 FIRST_COMPLETED / FIRST_EXCEPTION / ALL_COMPLETED 控制返回时机，适合“谁先完成谁处理、其余取消”的竞态选路。

三、取消与超时：CancelledError 是协作信号

1. 取消发生在“下一次机会”

task.cancel() 请求取消后，目标 Task 会在 下一次可取消点（通常是 await）注入 asyncio.CancelledError。官方建议：

用 try/finally 做资源清理（关连接、放回连接池、落盘状态）；
若显式 except CancelledError，清理完成后 一般应继续抛出；
CancelledError 直接继承 BaseException，因此普通 except Exception 抓不到它——这是刻意设计。

吞掉取消会破坏结构化并发组件：

asyncio.TaskGroup and asyncio.timeout() are implemented using cancellation internally and might misbehave if a coroutine swallows asyncio.CancelledError.

2. 超时：`wait_for` 与 `timeout` 上下文

# 超时后取消 awaitable，并抛 TimeoutError
try:
 await asyncio.wait_for(long_job(), timeout=5)
except TimeoutError:
 ...

wait_for 在超时路径会取消目标任务；为避免取消可包 shield（见下）。函数会等到取消真正完成，因此总等待可能略大于 timeout。

3.11+ 更推荐上下文管理器写法：

async def main():
 try:
 async with asyncio.timeout(10):
 await long_running_task()
 except TimeoutError:
 # TimeoutError 只能在 with 之外捕获
 ...

timeout 会取消 当前 Task，内部把 CancelledError 转成 TimeoutError。timeout_at(when) 用绝对 deadline，适合与外部截止时间对齐。

3. `shield`：挡外层取消，不挡内层自杀

res = await asyncio.shield(critical_section())

外层 Task 被取消时，critical_section 对应 Task 不一定 被取消；但从调用方看，await 仍会抛 CancelledError。若 critical_section 自己取消自己，shield 挡不住。完全“无视取消”通常不推荐——多数场景应清理后退出。

4. 可复现小实验：串行 vs 并发 vs 超时取消

把下面脚本存为 asyncio_lab.py，用本机 Python 3.11+ 直接跑，对照耗时与异常类型：

import asyncio
import time

async def work(name: str, delay: float, fail: bool = False):
 print(f"{name}: start")
 try:
 await asyncio.sleep(delay)
 if fail:
 raise RuntimeError(f"{name} failed")
 print(f"{name}: done")
 return name
 finally:
 print(f"{name}: cleanup")

async def demo_serial():
 t0 = time.perf_counter()
 await work("A", 1)
 await work("B", 1)
 print("serial_sec=", round(time.perf_counter() - t0, 2))

async def demo_concurrent():
 t0 = time.perf_counter()
 async with asyncio.TaskGroup() as tg:
 tg.create_task(work("A", 1))
 tg.create_task(work("B", 1))
 print("concurrent_sec=", round(time.perf_counter() - t0, 2))

async def demo_timeout_cancel():
 try:
 async with asyncio.timeout(0.3):
 await work("slow", 2)
 except TimeoutError:
 print("got TimeoutError as expected")

async def demo_swallow_cancel_bad():
 async def bad():
 try:
 await asyncio.sleep(10)
 except asyncio.CancelledError:
 print("swallowed cancel — TaskGroup/timeout 可能异常")
 # 反例：清理后应 re-raise
 return "oops"

 task = asyncio.create_task(bad())
 await asyncio.sleep(0.05)
 task.cancel()
 print("bad_result=", await asyncio.gather(task, return_exceptions=True))

async def main():
 await demo_serial()
 await demo_concurrent()
 await demo_timeout_cancel()
 await demo_swallow_cancel_bad()

if __name__ == "__main__":
 asyncio.run(main())

预期现象：

串行约 2s，并发约 1s，说明 await 串接 ≠ 并发；
超时路径打印 cleanup 后得到 TimeoutError（timeout 上下文在内部完成 CancelledError 转换）；
吞掉 CancelledError 会让任务“以普通返回值结束”，外层若误以为已取消，容易泄漏后续逻辑。

四、工程实践：从入口到排障

1. 入口与生命周期

async def app():
 # 创建共享资源：连接池、httpx.AsyncClient 等
 async with lifespan():
 await serve()

if __name__ == "__main__":
 asyncio.run(app(), debug=False) # 开发可 debug=True

需要在同一 loop 多次跑顶层协程时，用 asyncio.Runner 上下文，而不是嵌套 asyncio.run。

2. 阻塞调用迁出事件循环

def blocking_io():
 # 同步 SDK / 磁盘 / 旧库
 return open("/etc/hosts").read()

async def handler():
 data = await asyncio.to_thread(blocking_io)
 return data

to_thread 会传播 contextvars，适合 IO 型阻塞；CPU 密集可考虑进程池 executor。

3. 取消友好的业务骨架

async def fetch_with_cleanup(session, url):
 resp = None
 try:
 resp = await session.get(url)
 return await resp.text()
 finally:
 if resp is not None:
 await resp.aclose()

原则：

所有可能长时间 await 的路径都假定可被取消；
持有的锁、文件、连接在 finally 释放；
不要用裸 except Exception: pass 包住整段协程。

4. 并发扇出模板

async def fan_out(urls: list[str], limit: int = 20):
 sem = asyncio.Semaphore(limit)

 async def one(url: str):
 async with sem:
 return await fetch(url)

 async with asyncio.TaskGroup() as tg:
 tasks = [tg.create_task(one(u)) for u in urls]
 return [t.result() for t in tasks]

限流用 Semaphore，汇合用 TaskGroup，超时可在外层 async with asyncio.timeout(...) 包住整组或单个 one。

5. 调试开关

开发期打开 debug mode（任选其一）：

环境变量 PYTHONASYNCIODEBUG=1
asyncio.run(..., debug=True)
loop.set_debug(True)

debug 能更清楚地指出 never-awaited coroutine 的创建栈，并帮助发现慢回调。配合：

import logging
logging.basicConfig(level=logging.DEBUG)

6. 与多线程协作时的边界

官方 Developing with asyncio 写得很清楚：事件循环在一个线程里跑所有回调与 Task；几乎所有 asyncio 对象都不是线程安全的。从其他 OS 线程调度回调必须用 loop.call_soon_threadsafe(...)；从其他线程提交协程用 asyncio.run_coroutine_threadsafe(coro, loop)，它返回 concurrent.futures.Future。反向地，若只是要把阻塞函数丢出循环线程，优先 asyncio.to_thread，而不是自己裸开线程再回调 loop。

工程约束可以记成：

一个 loop 绑定一个线程（通常是主线程）；
跨线程只走 threadsafe API；
业务协程里不要 threading.Lock 长时间占着不 await——锁竞争会放大“假死”表象。

7. HTTP 扇出 + 首个成功取消其余

async def first_success(coros):
 tasks = [asyncio.create_task(c) for c in coros]
 try:
 while tasks:
 done, pending = await asyncio.wait(
 tasks, return_when=asyncio.FIRST_COMPLETED
 )
 for d in done:
 if d.exception() is None:
 for p in pending:
 p.cancel()
 # 收尾 pending，避免警告
 await asyncio.gather(*pending, return_exceptions=True)
 return d.result()
 tasks = list(pending)
 raise RuntimeError("all failed")
 finally:
 for t in tasks:
 if not t.done():
 t.cancel()

这是“多副本查询取最快”的常见模式：与 Go 里 fan-out + context cancel 同构，只是取消载体从 context.Context 换成了 Task.cancel / CancelledError。

五、常见坑与排查清单

症状	可能根因	排查/修复
`RuntimeWarning: coroutine 'x' was never awaited`	写了 `x()` 却未 `await`/`create_task`	打开 debug；全文搜未 await 的调用
后台任务“跑一半消失”	只 `create_task` 未保存强引用	`set` + `add_done_callback(discard)`
整体 QPS 骤降、延迟抖动	协程内同步阻塞	火焰图/`asyncio` 慢回调日志；改 `to_thread`
超时后连接仍占满	取消路径无 `finally` 清理	统一 async context manager
`TaskGroup` / `timeout` 行为怪异	`except CancelledError: pass` 吞取消	清理后 re-raise；勿滥用 `uncancel`
Jupyter/已有 loop 报错	嵌套 `asyncio.run`	用框架提供的 loop / `Runner` / `await` 直接写
取消不及时	长段纯计算无 `await`	拆分、主动 `await asyncio.sleep(0)` 让出（治标）或迁线程/进程（治本）

快速自检脚本思路：

# 1) 开发模式跑入口
PYTHONASYNCIODEBUG=1 python app.py

# 2) 确认没有 never-awaited
# 3) 压测时观察是否仅单核打满且无网络等待（疑似阻塞循环）

六、总结

asyncio 是单线程协作式并发：await 是让出点；阻塞代码会冻住所有 Task。
协程对象 ≠ 已调度任务：入口用 asyncio.run，并发用 create_task / TaskGroup。
Task 只有弱引用：fire-and-forget 必须自管强引用集合。
取消是协作语义：CancelledError 属 BaseException；清理后应继续传播，否则破坏 TaskGroup/timeout。
超时优先结构化 API：asyncio.timeout / wait_for；关键段可 shield，但不要“永远不退出”。
阻塞 IO 迁出循环：to_thread / executor；开发期打开 debug 抓 never-awaited 与慢回调。

掌握“调度模型 + 取消契约 + 结构化汇合”，比背一长串 API 更能写出可维护的异步服务。

事件循环 on 吾爱主机

Node.js 事件循环与 nextTick / microtask：原理、阶段与工程实践

一、问题背景：单线程 JS 为何能扛大量并发

二、核心模型：阶段队列 + 阶段外的 nextTick

1. 启动与相位图

2. 各 phase 在工程上的含义

3. process.nextTick 不在相位图里

4. setImmediate vs setTimeout(0)

三、实践：可复现实验

实验 A：I/O 周期内 immediate 恒先于 timeout(0)

实验 B：nextTick 在“当前操作后”插入，早于进入下一 phase

实验 C：为何 API 必须“全同步或全异步”

实验 D：同步计算堵死循环（对照）

四、常见坑与排查

五、总结

参考资料

Python asyncio 事件循环与 Task 取消：原理、API 与工程实践

一、问题背景：并发不等于多线程

二、核心模型：协作式调度 + 弱引用 Task

1. 必须“跑起来”，而不能只“创建”

2. 并发来自 Task，不是“多写几个 await”

3. 结构化并发：优先 TaskGroup（3.11+）

三、取消与超时：CancelledError 是协作信号

1. 取消发生在“下一次机会”

2. 超时：wait_for 与 timeout 上下文

3. shield：挡外层取消，不挡内层自杀

4. 可复现小实验：串行 vs 并发 vs 超时取消

四、工程实践：从入口到排障

1. 入口与生命周期

2. 阻塞调用迁出事件循环

3. 取消友好的业务骨架

4. 并发扇出模板

5. 调试开关

6. 与多线程协作时的边界

7. HTTP 扇出 + 首个成功取消其余

五、常见坑与排查清单

六、总结

参考资料

3. `process.nextTick` 不在相位图里

4. `setImmediate` vs `setTimeout(0)`

3. 结构化并发：优先 `TaskGroup`（3.11+）

2. 超时：`wait_for` 与 `timeout` 上下文

3. `shield`：挡外层取消，不挡内层自杀