并发 on 吾爱主机

Go channel 与 select：阻塞语义、关闭规则与工程实践

Wed, 29 Jul 2026 00:00:00 +0800

goroutine 之间如何安全地交换数据、如何表达“没有更多结果了”、如何在多个就绪通道里做非确定性选择——这些都落在 channel 与 select 上。Go 语言规范把 channel 定义为并发函数之间按指定元素类型发送/接收的通信机制；官方博客的口号则是：

Do not communicate by sharing memory; instead, share memory by communicating.

本文依据 Go 语言规范（Channel types / Send / Receive / close / Select statements）、Effective Go 的 Channels 章节、官方博客 Share Memory By Communicating 与 Go Concurrency Patterns: Pipelines and cancellation，把无缓冲/有缓冲阻塞规则、关闭语义、select 调度、管道关闭与取消讲清楚，并给出可复现实验与排错清单。它和「context 取消传播」互补：context 解决“该停了”，channel/select 解决“值怎么传、何时结束、多路怎么选”。

一、问题背景：共享内存锁 vs 通道通信

传统多线程模型里，线程通过共享数据结构 + 锁协作：谁拿到锁谁改状态。Go 的 CSP 风格把协作点显式化——发送/接收本身就是同步点。

常见踩坑往往不是“不会写 ch <- v”，而是对阻塞条件判断错误：

无缓冲通道上“先发后收”在单 goroutine 里会永久阻塞；
向已关闭通道发送触发 runtime panic；
对 nil 通道发送/接收会永远阻塞，select 里一不小心就“整段卡死”；
只 close 不约定所有权，多发送者并发 close 直接 panic；
管道中游生产者退出却不 close，下游 range 永不结束。

把规范里的规则记成表，比背 API 更有用。

二、核心模型：无缓冲握手与有缓冲队列

1. 创建与零值

var ch chan int // nil channel，零值
ch = make(chan int) // 无缓冲（容量 0）
ch2 := make(chan int, 0) // 同样无缓冲
buf := make(chan int, 8) // 缓冲容量 8

规范要点：

概念	规范语义	工程含义
元素类型	`chan T` / 方向 `chan<- T`、`<-chan T`	编译期限制发送/接收方向
make 容量	可选 capacity；0 或省略 → unbuffered	无缓冲 = 同步通信
缓冲通道	缓冲未满可发送、非空可接收且不阻塞	解耦生产/消费速率
零值 nil	未初始化的 channel 为 nil	对 nil 收发会永久阻塞
FIFO	通道是先进先出队列	多 goroutine 共用同一通道无需额外同步结构（仍要注意关闭约定）

无缓冲通道：只有发送方与接收方都就绪时通信才成功——值直接从发送方拷到接收方，同时完成同步。有缓冲通道：发送在缓冲有空位时即可完成；接收在缓冲有数据时即可完成。

Effective Go 的表述更偏工程直觉：

接收方总是阻塞到有数据可收；
无缓冲时，发送方阻塞到接收方取走值；
有缓冲时，发送方阻塞到值被拷入缓冲；缓冲满则等到有接收方腾出空位。

2. 发送 / 接收何时可推进

规范对 send 的可推进条件可以压缩成：

操作	可立即推进的条件	否则
无缓冲发送	已有接收方就绪	阻塞
有缓冲发送	缓冲未满	阻塞
向 closed 发送	—	runtime panic
向 nil 发送	—	永久阻塞
接收（开通道）	有数据或有发送方（无缓冲握手）	阻塞
从 closed 接收	总是可立即推进	先排空缓冲，再得到零值
从 nil 接收	—	永久阻塞

// 无缓冲：必须另一端参与
ch := make(chan string)
go func() { ch <- "ready" }()
msg := <-ch

// 有缓冲：容量内发送不阻塞
b := make(chan int, 2)
b <- 1
b <- 2
// b <- 3 // 若无接收方，此处阻塞

3. 关闭、ok 与 range

内建 close(ch) 表示“不会再有新值”。规范与管道博客共同强调的接收语义：

关闭后，先前已发送、仍在缓冲中的值会被正常接收完；
排空后，接收立即返回元素类型零值且不阻塞；
双返回值形式 v, ok := <-ch：ok == false 表示通道已关闭且没有更多值；
close(nil)、close 已关闭通道 → runtime panic；
向已关闭通道发送 → panic（这是最常见的线上事故之一）。

out := make(chan int, 3)
out <- 1
out <- 2
close(out)

for v := range out { // 自动在关闭且排空后结束
 fmt.Println(v)
}
v, ok := <-out
fmt.Println(v, ok) // 0 false

关闭约定（工程硬规则）：

发送侧关闭：通常由唯一“拥有发送权”的一方 close；多个发送者需要额外同步（例如用 sync.Once 或先汇合再 close）。
接收侧不要 close（除非协议明确且全局只有你发送——极少见）。
需要“广播停工”时，更常见的是 close 一个只读 done 信号通道（见下文管道取消），而不是让每个工作通道被多方乱关。

三、select：多路就绪与非确定性选择

select 像 switch，但 case 全部是通信操作。规范给出的执行步骤值得逐条对照代码：

进入 select 时，按源码顺序对所有 case 的通道操作数（以及发送右侧表达式）各求值恰好一次——副作用一定会发生，与最终选中哪个 case 无关；
若一个或多个通信可推进，用均匀伪随机选中其中一个；
若都不能推进且存在 default，走 default；
若都不能推进且无 default，阻塞直到至少一个可推进；
仅有 nil 通道 且无 default 的 select 永久阻塞。

select {
case v := <-a:
 handleA(v)
case b <- x:
 // 发送成功
case <-time.After(200 * time.Millisecond):
 // 超时分支（timer channel）
default:
 // 非阻塞探测：此刻无人可通信
}

工程模式

1）非阻塞试探（try-send / try-recv）

select {
case ch <- job:
default:
 // 队列满或无接收方：降级、丢弃或写指标
}

Effective Go 用 free-list + select/default 演示：缓冲通道兼作资源池，满则新建。

2）有缓冲通道当信号量

sem := make(chan struct{}, MaxOutstanding)

func handle(r *Request) {
 sem <- struct{}{} // 占坑；满则阻塞
 defer func() { <-sem }() // 释放
 process(r)
}

容量限制同时在飞的 process 数。注意：若外层对每个请求都 go handle 而不做接纳控制，仍可能制造海量 goroutine——需要在入口再限流。

3）与 context 组合：可取消等待

select {
case res := <-resultCh:
 return res, nil
case <-ctx.Done():
 return nil, ctx.Err()
}

channel 负责传结果，context 负责传“该停了”。二者不要互相替代。

四、可复现实验：阻塞、关闭与 select

下面用标准库即可在本机验证规范语义（Go 1.20+ 均可）。

package main

import (
 "fmt"
 "time"
)

func mustPanic(name string, fn func()) {
 defer func() {
 if r := recover(); r != nil {
 fmt.Println(name, "panic OK:", r)
 } else {
 fmt.Println(name, "ERROR: expected panic")
 }
 }()
 fn()
}

func main() {
 // 1) 无缓冲：单 goroutine 发送会死锁（用超时模拟探测）
 ub := make(chan int)
 go func() {
 select {
 case ub <- 1:
 fmt.Println("unexpected send success")
 case <-time.After(50 * time.Millisecond):
 fmt.Println("unbuffered send blocked as expected")
 }
 }()
 time.Sleep(80 * time.Millisecond)

 // 2) 有缓冲：容量内不阻塞
 b := make(chan int, 1)
 b <- 42
 fmt.Println("buffered len/cap:", len(b), cap(b))

 // 3) 关闭后接收
 close(b)
 v, ok := <-b
 fmt.Println("drain closed:", v, ok) // 42 true
 v, ok = <-b
 fmt.Println("after empty:", v, ok) // 0 false

 // 4) 向关闭通道发送 → panic
 mustPanic("send-on-closed", func() { b <- 1 })

 // 5) close(nil) → panic
 var n chan int
 mustPanic("close-nil", func() { close(n) })

 // 6) select 伪随机：两个都就绪时多次运行会看到不同分支
 a1, a2 := make(chan int, 1), make(chan int, 1)
 a1 <- 1
 a2 <- 2
 counts := map[string]int{}
 for i := 0; i < 200; i++ {
 // 重新填满，保证两 case 均可推进
 select {
 case <-a1:
 counts["a1"]++
 a1 <- 1
 case <-a2:
 counts["a2"]++
 a2 <- 2
 }
 }
 fmt.Println("select distribution:", counts)

 // 7) 仅 nil + 无 default：用超时包裹，避免真死锁进程
 var nilCh chan int
 select {
 case <-nilCh:
 fmt.Println("unreachable")
 case <-time.After(50 * time.Millisecond):
 fmt.Println("nil-only select would block forever without timeout")
 }
}

预期观察：

无缓冲在无人接收时发送走超时分支；
关闭通道先拿到缓冲残留，再 ok=false；
向关闭通道发送、close(nil) 触发 panic；
双就绪 select 的计数大致接近（伪随机，不保证 50/50 精确）。

五、管道：关闭传播与 done 取消

官方 Pipelines 博客的模型：

A pipeline is a series of stages connected by channels, where each stage is a group of goroutines running the same function.

每阶段从上游 channel 读、处理后写入下游 channel。结束信号有两种常见方式：

关闭数据通道：表示“没有更多输入”。因对已关闭通道的接收总可立即完成，下游 range 能自然退出；发送方在发完后 close(out)。
显式取消（done channel）：当下游提前退出、不再消费时，上游若继续发送会阻塞。博客做法是额外传入 done <-chan struct{}，由下游（或 main）close(done) 做广播，上游在 select 里同时监听 done 与数据发送，从而放弃未完成发送。

func gen(done <-chan struct{}, nums ...int) <-chan int {
 out := make(chan int)
 go func() {
 defer close(out)
 for _, n := range nums {
 select {
 case out <- n:
 case <-done:
 return
 }
 }
 }()
 return out
}

// main 中：
done := make(chan struct{})
defer close(done) // 退出时广播取消
for n := range sq(done, gen(done, 2, 3)) {
 fmt.Println(n)
 break // 提前结束也安全：done 关闭后上游不再堵在发送上
}

这与 context 的取消树是同一思想的两种载体：done 通道是轻量广播；复杂调用链更推荐 context.Context。

六、常见坑与排查清单

症状	可能根因	排查 / 修复
`fatal error: all goroutines are asleep - deadlock!`	无缓冲自收自发；所有 goroutine 互相等待	用 `go` 起对端；检查是否缺接收/发送
`panic: send on closed channel`	接收方误 close，或多发送者重复 close	单一发送所有者 close；多生产者用 WaitGroup 汇合后再 close
`panic: close of closed channel` / `close of nil channel`	重复 close 或 close 零值	`sync.Once`；初始化后再 close
goroutine 数量持续上涨	发送阻塞无人收；`go handle` 无限接纳	有缓冲限流 + context 取消；pprof `goroutine`
`range` 永不结束	上游未 close	契约：最后一个发送者负责 close
select “总是”走同一分支	另一 case 实际不可推进（nil/满/空）	打印 `len/cap`、是否 nil、是否已 close
定时器泄漏	`time.After` 在热路径大量创建	复用 `time.NewTimer` 并 `Stop`
数据竞争仍在	channel 传的是指针/切片头，共享底层数组	发送所有权转移；或拷贝；或明确只读契约

补充 runtime 视角（runtime/chan.go 注释）：缓冲通道上，缓冲非空时接收队列为空、缓冲未满时发送队列为空——实现上把“数据在缓冲”与“对端在等待队列”分成清晰不变量。排障时你不需要背这些字段，但要理解：阻塞 = 进入 sendq/recvq 等待被对端或 close 唤醒。

七、总结

无缓冲 channel = 通信 + 同步；有缓冲 = 带容量的 FIFO，用于削峰与信号量。
关闭是“不再发送”的信号，不是“销毁”；排空后接收零值；禁止向已关闭通道发送。
nil 通道收发永久阻塞；select 求值有副作用，多就绪 case 伪随机，无就绪且无 default 则阻塞。
管道靠 close 数据通道 表达结束，靠 done/context 表达提前取消，避免上游堵死。
与上一篇 Go context 取消传播 搭配：context 管生命周期，channel/select 管数据面与多路选择。

把“谁发送、谁关闭、谁取消、缓冲多大”四件事写进代码评审清单，比事后查 deadlock 日志便宜得多。

参考资料

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 更能写出可维护的异步服务。

参考资料

Go context 取消传播与超时控制：原理、API 与工程实践

Sat, 18 Jul 2026 00:00:00 +0800

HTTP 请求被客户端断开、下游 RPC 超时、批量任务需要“先完成的取消其余副本”——这些场景的共同点是：一组协作的 goroutine 必须能收到“该停了”的信号，并在约定时间内释放资源。Go 标准库的 context 包，就是为跨 API 边界传递 截止时间（deadline）、取消信号 与 请求级值 而设计的。

本文基于 context 包源码注释、pkg.go.dev/context 文档，以及 Go 官方博客 Go Concurrency Patterns: Context、Contexts and structs，把取消树、超时、CancelFunc 泄漏、WithValue 边界与常见工程坑讲清楚，并给出可落地的写法与排查清单。

一、问题背景：为什么需要 Context

没有统一取消通道时，常见反模式是：

每个函数自建 done chan struct{}，调用链一长就无法串联；
超时只写在 HTTP Client 上，业务层仍继续跑昂贵计算；
子 goroutine 不知道请求已结束，继续访问已关闭的连接，造成泄漏或写日志噪音。

官方文档的定位非常明确：

Package context defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes.

工程上可以记三句话：

能力	含义	典型触发
Deadline	工作最晚何时必须结束	`WithTimeout` / `WithDeadline`
Cancellation	调用方主动要求放弃	客户端断开、`cancel()`、父 context 取消
Request-scoped values	跨边界透传的请求元数据	trace id、鉴权主体（慎用）

服务入口应为入站请求创建 Context；出站调用应接收并传播同一个（或派生的）Context。中间调用链 必须向下传递，必要时用 WithCancel / WithTimeout / WithValue 派生子 Context。

二、核心模型：取消树 + Done 通道

Context 是接口，核心方法包括 Done、Err、Deadline、Value。理解取消的关键是：

Done() <-chan struct{}：通道关闭即“应停止工作”的信号；
Err()：在 Done 关闭后说明原因——context.Canceled 或 context.DeadlineExceeded；
派生形成树：父 Context 取消时，所有子 Context 一并取消；
接收方不能取消父方：Context 没有 Cancel 方法，Done 只读，避免子操作反过来取消父操作。

官方博客强调：父操作启动子操作时，子操作不应有能力取消父操作；取消权通过 WithCancel 返回的 CancelFunc 交给“拥有者”。

Background / request root
 │
 ├─ WithTimeout(2s) ──► handler 工作树
 │ │
 │ ├─ WithCancel ──► 并行查询 A
 │ └─ WithCancel ──► 并行查询 B
 │
 └─ 根取消 / 超时 / cancel()
 ⇒ 整棵子树 Done 关闭

Background() 返回永不取消、无值、无 deadline 的空 Context，适合 main、初始化、测试，以及入站请求的顶层根。TODO() 同样是空 Context，用于“暂时不清楚该用哪个 Context”的占位；不要传 nil——文档明确要求：即使函数允许 nil，也请传 context.TODO()。

三、API 速查：从根到超时

1. 取消：`WithCancel` / `WithCancelCause`

ctx, cancel := context.WithCancel(parent)
defer cancel() // 工作结束后尽快调用，释放子树与定时器资源

语义要点（源码注释）：

子 Context 的 Done 在 cancel() 被调用 或 父 Done 关闭 时关闭，谁先发生谁生效；
调用 cancel 会取消子及其后代，并断开父对子的引用、停止相关 timer；
不调用 CancelFunc 会泄漏：子 Context 及其后代会一直挂到父被取消；go vet 会检查所有控制流路径是否使用了 CancelFunc；
CancelFunc 不等待工作真正停下；可被多 goroutine 并发调用，首次之后为 no-op。

Go 1.20+ 的 cause 系列更利于排障：

ctx, cancel := context.WithCancelCause(parent)
cancel(fmt.Errorf("client disconnected: %w", err))
// ctx.Err() 仍为 context.Canceled
// context.Cause(ctx) 可取到你记录的 cause

Cause(ctx)：若通过 CancelCauseFunc(err) 取消则返回该 err；否则与 ctx.Err() 相同；未取消时返回 nil。

2. 超时与截止时间：`WithTimeout` / `WithDeadline`

// WithTimeout ≡ WithDeadline(parent, time.Now().Add(timeout))
ctx, cancel := context.WithTimeout(parent, 100*time.Millisecond)
defer cancel()
return slowOperation(ctx)

语义要点：

子 deadline 取 parent deadline 与新 deadline 中更早者；
Done 在 超时 / cancel / 父取消 三者中最先发生时关闭；
超时后 ctx.Err() 为 context.DeadlineExceeded；主动 cancel 一般为 context.Canceled；
同样必须 defer cancel()，即使操作在超时前完成，也要释放 timer 等资源。

3. 值：`WithValue`（窄场景）

type traceIDKey struct{}
ctx = context.WithValue(ctx, traceIDKey{}, "req-42")

官方硬规则：

只用于跨进程/API 传递的请求级数据，不要把可选函数参数塞进 Context；
key 必须 comparable，且 不要用内置 string 等类型当 key，避免包间碰撞；推荐自定义未导出类型，如 struct{}。

4. 进阶：`WithoutCancel` 与 `AfterFunc`（Go 1.21+）

API	用途	注意
`WithoutCancel(parent)`	派生一个不随父取消的 Context；无 Deadline/Err，Done 为 nil	父 nil 会 panic；适合“请求已结束但仍要落盘审计”的短尾工作，且必须自建超时
`AfterFunc(ctx, f)`	ctx 取消后在独立 goroutine 跑 `f`；已取消则立即调度	返回 `stop`；`stop` 不等待 `f` 结束；多次 `AfterFunc` 彼此独立

四、实践：HTTP 处理中的超时与协作取消

func handleSearch(w http.ResponseWriter, r *http.Request) {
 // 入站请求：以 r.Context() 为根（客户端断开时通常会取消）
 parent := r.Context()

 // 业务总预算：2s（与网关/客户端超时对齐，略留余量）
 ctx, cancel := context.WithTimeout(parent, 2*time.Second)
 defer cancel()

 q := r.URL.Query().Get("q")
 result, err := searchBackends(ctx, q)
 if err != nil {
 if errors.Is(err, context.DeadlineExceeded) {
 http.Error(w, "search timeout", http.StatusGatewayTimeout)
 return
 }
 if errors.Is(err, context.Canceled) {
 // 客户端已走，通常无需再写完整响应
 return
 }
 http.Error(w, err.Error(), http.StatusBadGateway)
 return
 }
 // ... 写响应
}

func searchBackends(ctx context.Context, q string) (string, error) {
 // 扇出：任一成功可取消其余；或全部失败返回
 ctx, cancel := context.WithCancel(ctx)
 defer cancel()

 type res struct {
 v string
 err error
 }
 ch := make(chan res, 2)

 for _, ep := range []string{"a.example", "b.example"} {
 ep := ep
 go func() {
 v, err := callOne(ctx, ep, q) // 内部必须监听 ctx.Done()
 ch <- res{v, err}
 }()
 }

 var last error
 for i := 0; i < 2; i++ {
 select {
 case <-ctx.Done():
 return "", context.Cause(ctx) // 或 ctx.Err()
 case r := <-ch:
 if r.err == nil {
 cancel() // 提前结束兄弟 goroutine
 return r.v, nil
 }
 last = r.err
 }
 }
 return "", last
}

func callOne(ctx context.Context, ep, q string) (string, error) {
 req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://"+ep+"/s?q="+url.QueryEscape(q), nil)
 if err != nil {
 return "", err
 }
 resp, err := http.DefaultClient.Do(req)
 if err != nil {
 return "", err
 }
 defer resp.Body.Close()
 // ... 读 body，同样尊重 ctx
 return "ok", nil
}

协作取消的正确姿势：

叶子操作用支持 Context 的 API（NewRequestWithContext、QueryContext、gRPC ctx 等）；
纯计算循环用 select 或周期性检查 ctx.Err()；
取消是 建议性（advisory） 的：库必须真正监听 Done，否则 cancel() 只是“通知了空气”。

五、不要把 Context 塞进结构体

官方文档与 Contexts and structs 博客一致：

Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. The Context should be the first parameter, typically named ctx.

六、常见坑与排查

症状	可能原因	处理
goroutine / timer 泄漏	创建了 `WithCancel`/`WithTimeout` 却没 `cancel`	立刻 `defer cancel()`；跑 `go vet`
超时不生效	底层调用未绑定 ctx（旧 `http.Get`、忽略 Done 的循环）	换 `*Context` API；手写 `select`
`Err` 总是 Canceled 难排查	未区分超时与主动取消	用 `errors.Is`；需要细节时用 Cause 系列
请求结束后仍用原 ctx 写库	父 ctx 已取消导致落库失败	短尾任务用新的 `WithTimeout(context.Background(), …)` 或审慎使用 `WithoutCancel` + 自有超时
值取不到 / 键冲突	string key 跨包碰撞或类型断言错误	私有 key 类型 + 统一 accessor
把可选参数塞进 Value	隐式依赖、难测	显式函数参数
传递 `nil` context	派生时 panic 或行为未定义	`TODO()` / `Background()`

最小实验建议：

A. WithTimeout(50ms) + time.Sleep(200ms) 并 select ctx.Done()
 期望：DeadlineExceeded

B. 父 WithCancel，子 WithTimeout(1s)，父先 cancel
 期望：子立刻 Done，Err 为 Canceled（父取消优先于子 timer）

C. WithTimeout 成功路径忘记 defer cancel
 观察：高频调用下 timer/子节点滞留（pprof / 泄漏检测）

D. Worker 存 ctx vs 每方法传 ctx
 对比：后者可为单次调用设更短 deadline

七、工程约定（可直接用于 Code Review）

ctx 永远是第一个参数，命名 ctx；不放结构体字段。
入站用框架/request 的 Context；出站必须向下传，禁止“半路换成 Background”除非有书面理由（如与请求脱钩的异步任务）。
每个 WithCancel / WithTimeout / WithDeadline 成对 defer cancel()。
超时预算 自上而下递减：网关 3s → 服务 2s → 下游 RPC 800ms，避免子超时大于父。
WithValue 仅 trace/auth 等横切元数据；业务输入走参数。
错误判断用 errors.Is(err, context.Canceled) / DeadlineExceeded，不要比字符串。
取消后仍需完成的短工作：新建带超时的独立 Context，并限队列，防止雪崩。
并发扇出时明确策略：全部完成 / 先胜出取消其余 / 错误阈值，并保证兄弟 goroutine 能收到取消。

八、总结

context 不是“多传一个参数”的仪式，而是 Go 并发里 跨边界的截止时间与取消协议：

取消沿 父子树 向下传播；子不能取消父；
WithTimeout / WithDeadline 用更紧的 deadline 保护尾延迟；
CancelFunc 必须调用，否则泄漏到父取消为止；
协作取消要求叶子真正监听 Done；
Context 作参数传递，不进结构体；Value 只承载请求级元数据。

把“谁拥有 cancel、超时预算如何切分、叶子是否尊重 Done”三件事写进设计与 Code Review，线上超时与 goroutine 泄漏类问题会少一个数量级。

参考资料

Go 标准库文档 — context package（Overview、WithCancel/WithTimeout/WithValue/WithoutCancel/AfterFunc/Cause、编程约定）
Go 源码 — src/context/context.go（包注释与 API 语义、Canceled/DeadlineExceeded、CancelFunc 行为）
Go Blog — Go Concurrency Patterns: Context（Context 接口、派生树、Background、服务端示例动机）
Go Blog — Contexts and structs（为何不要把 Context 存进结构体、按调用传参的生命周期清晰性）

并发 on 吾爱主机

Go channel 与 select：阻塞语义、关闭规则与工程实践

一、问题背景：共享内存锁 vs 通道通信

二、核心模型：无缓冲握手与有缓冲队列

1. 创建与零值

2. 发送 / 接收何时可推进

3. 关闭、ok 与 range

三、select：多路就绪与非确定性选择

工程模式

四、可复现实验：阻塞、关闭与 select

五、管道：关闭传播与 done 取消

六、常见坑与排查清单

七、总结

参考资料

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 扇出 + 首个成功取消其余

五、常见坑与排查清单

六、总结

参考资料

Go context 取消传播与超时控制：原理、API 与工程实践

一、问题背景：为什么需要 Context

二、核心模型：取消树 + Done 通道

三、API 速查：从根到超时

1. 取消：WithCancel / WithCancelCause

2. 超时与截止时间：WithTimeout / WithDeadline

3. 值：WithValue（窄场景）

4. 进阶：WithoutCancel 与 AfterFunc（Go 1.21+）

四、实践：HTTP 处理中的超时与协作取消

五、不要把 Context 塞进结构体

六、常见坑与排查

七、工程约定（可直接用于 Code Review）

八、总结

参考资料

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

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

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

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

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

1. 取消：`WithCancel` / `WithCancelCause`

2. 超时与截止时间：`WithTimeout` / `WithDeadline`

3. 值：`WithValue`（窄场景）

4. 进阶：`WithoutCancel` 与 `AfterFunc`（Go 1.21+）