Goroutine 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 日志便宜得多。

参考资料

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 存进结构体、按调用传参的生命周期清晰性）

Goroutine on 吾爱主机

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

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

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

1. 创建与零值

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

3. 关闭、ok 与 range

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

工程模式

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

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

六、常见坑与排查清单

七、总结

参考资料

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

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

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

三、API 速查：从根到超时

1. 取消：WithCancel / WithCancelCause

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

3. 值：WithValue（窄场景）

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

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

五、不要把 Context 塞进结构体

六、常见坑与排查

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

八、总结

参考资料

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

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

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

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