context
需要预先了解：
1. context
一个请求往往要派生多个 goroutine：查数据库、调下游服务、写日志。如果其中一步超时或客户端断开，其他步骤需要尽快停下。context 就是用来统一传递取消信号、截止时间和请求范围内的元数据的标准机制。
1.1 需求引入
假设一个函数要并发做三件事，任何一件失败或超时就整体放弃。如果每个 goroutine 各自用 done channel，代码会变成一堆手写的通知逻辑：
done1 := make(chan struct{})
done2 := make(chan struct{})
// 谁来关闭？超时怎么办？取消要不要级联？context 把这些问题标准化：它是一棵可级联取消的树，父节点取消时所有子节点都会收到通知。
1.2 Context 接口
type Context interface {
Deadline() (deadline time.Time, ok bool)
Done() <-chan struct{}
Err() error
Value(key any) any
}四个方法的职责：
| 方法 | 作用 |
|---|---|
Deadline |
返回截止时间，第二个返回值表示是否设置了截止时间 |
Done |
返回一个 channel，context 被取消时它被关闭 |
Err |
context 结束后返回原因：context.Canceled 或 context.DeadlineExceeded |
Value |
取出与该 context 关联的值 |
Done 是唯一必须用的方法——它让你能 select 等待取消。Err 通常在收到取消后调用，用来区分"被主动取消"和"超时"。
1.3 根 context
所有 context 树都从两个根之一开始：
context.Background()：主函数、初始化、测试中作为根使用；context.TODO()：暂时不知道该传什么时的占位。
两者都是空的、不可取消的 context，行为完全一样，区别只在语义：TODO 表示"这里以后要换成真正的 context"。
1.4 派生 context
WithCancel
ctx, cancel := context.WithCancel(context.Background())
defer cancel() // 一定要调用，否则会泄漏cancel() 关闭 ctx.Done()，并把取消信号传播给所有派生子节点。
WithTimeout / WithDeadline
ctx, cancel := context.WithTimeout(parent, 50*time.Millisecond)
defer cancel()
ctx2, cancel2 := context.WithDeadline(parent, time.Now().Add(30*time.Millisecond))
defer cancel2()WithTimeout 就是 WithDeadline(parent, time.Now().Add(d)) 的简写。超时后 ctx.Err() 返回 context.DeadlineExceeded。
即使设置了超时，也要 defer cancel()：提前完成时取消可以释放定时器资源，避免等到超时才被 GC。
WithValue
type key string
ctx := context.WithValue(context.Background(), key("traceID"), "abc-123")
if v, ok := ctx.Value(key("traceID")).(string); ok {
fmt.Println("traceID =", v) // abc-123
}key 建议用自定义类型（比如 type key string）而不是裸字符串，避免不同包之间撞 key。Value 里只放请求范围的元数据（trace ID、用户身份、认证信息），不要放业务参数或可选参数。
树形结构与传播
context.Background()
|
WithCancel（请求级）
/ \
WithTimeout WithValue
| |
worker A worker B传播规则：
- 取消父节点 → 所有子孙节点都被取消；
- 取消子节点 → 父节点和其他兄弟节点不受影响。
parent, cancelParent := context.WithCancel(context.Background())
child1, cancel1 := context.WithCancel(parent)
child2, cancel2 := context.WithCancel(parent)
defer cancel1()
defer cancel2()
cancelParent()
time.Sleep(50 * time.Millisecond)
fmt.Println("child1.Err() =", child1.Err()) // context canceled
fmt.Println("child2.Err() =", child2.Err()) // context canceled反向取消：
child3, cancel3 := context.WithCancel(parent2)
cancel3()
fmt.Println("child3.Err() =", child3.Err(), "parent2.Err() =", parent2.Err())child3.Err() = context canceled parent2.Err() = <nil>1.5 使用惯例
ctx作为函数的第一个参数，命名为ctx：func Fetch(ctx context.Context, id int) (*User, error)- 不要把
ctx存进结构体。它是请求级对象，存进结构体会让生命周期难以追踪。例外是http.Request这类本身携带请求上下文的结构体。 ctx可以为 nil 吗？ 不可以，绝大多数函数会直接调用ctx.Done()，传 nil 会 panic。不确定时传context.TODO()。- 只在真正需要取消的层级派生。不要每个函数都
WithCancel，否则取消链很长，cancel容易忘记调用。 Value不要用来传业务参数。业务参数应该显式出现在函数签名里，否则调用方无法从签名知道依赖了什么。
1.6 新增 API
WithCancelCause 与 Cause（Go 1.20+）
默认的取消原因是 context.Canceled，无法区分"为什么取消"。带 cause 的版本可以携带具体错误：
ctx, cancel := context.WithCancelCause(context.Background())
cancel(errors.New("数据库连接失败"))
<-ctx.Done()
fmt.Println("ctx.Err() =", ctx.Err()) // context canceled
fmt.Println("context.Cause =", context.Cause(ctx)) // 数据库连接失败ctx.Err() 仍然是 context.Canceled，具体原因通过 context.Cause(ctx) 获取。
AfterFunc（Go 1.21+）
在 context 被取消时执行一个函数，不需要自己起 goroutine 等待 Done：
ctx, cancel := context.WithCancel(context.Background())
done := make(chan struct{})
context.AfterFunc(ctx, func() { close(done) })
cancel()
<-done
fmt.Println("AfterFunc 的回调被触发")返回值 stop 可以取消这个注册：
stop := context.AfterFunc(ctx2, func() { fmt.Println("这行不会打印") })
fmt.Println("stop() 返回值:", stop()) // trueWithoutCancel（Go 1.21+）
派生一个不随父节点取消的 context，但保留其中的值：
parent, cancelParent := context.WithCancel(context.Background())
ctx := context.WithValue(parent, "k", "v")
detached := context.WithoutCancel(ctx)
cancelParent()
fmt.Println("parent.Err() =", parent.Err()) // context canceled
fmt.Println("detached.Err() =", detached.Err()) // <nil>
fmt.Println("值仍然保留:", detached.Value("k")) // v典型用途：请求结束后仍要写审计日志、上报指标——这些操作不应该因为客户端断开就被取消。
1.7 可取消的 worker
把 context 和 select 组合起来，就是最常见的可取消任务模式：
func worker(ctx context.Context, id int) {
for i := 1; ; i++ {
select {
case <-ctx.Done():
fmt.Printf("worker %d 收到取消信号: %v\n", id, ctx.Err())
return
default:
time.Sleep(30 * time.Millisecond)
fmt.Printf("worker %d 完成第 %d 轮\n", id, i)
}
}
}ctx, cancel := context.WithCancel(context.Background())
defer cancel()
go worker(ctx, 1)
go worker(ctx, 2)
time.Sleep(80 * time.Millisecond)
cancel()
time.Sleep(50 * time.Millisecond)输出（顺序不固定）：
worker 1 完成第 1 轮
worker 2 完成第 1 轮
worker 2 完成第 2 轮
worker 1 完成第 2 轮
取消 parent
worker 2 完成第 3 轮
worker 2 收到取消信号: context canceled
worker 1 完成第 3 轮
worker 1 收到取消信号: context canceled关键点：
select同时等待"取消信号"和"继续工作"；- 收到取消后立即
return，不要再启动新的工作； - 如果 worker 阻塞在 IO 上，要把
ctx传给 IO 函数（标准库的http.NewRequestWithContext、db.QueryContext都接收ctx）。
1.8 标准库中的 ctx
context 是标准库的一等公民，很多 API 都带 ctx 参数：
// net/http：带超时的请求
req, _ := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
resp, err := http.DefaultClient.Do(req)
// database/sql：带取消的查询
row := db.QueryRowContext(ctx, "SELECT name FROM users WHERE id = ?", id)// 服务端从请求里取 context
func handler(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
// ...
}HTTP 服务的优雅关闭、请求超时、下游调用取消，都建立在这套机制上，详见 标准库（二）：JSON 与 HTTP 服务。
注：
context只负责"通知取消"，不负责"强制终止"。收到取消信号后是否立刻停止，由你的代码决定。定时器、channel、IO 都要显式处理取消，否则 goroutine 依然会泄漏。
1.9 练习
- 实现一个函数，用
context.WithTimeout限制总耗时，内部并发请求三个"慢服务"（用time.Sleep模拟），任何一个超时就返回错误。 - 用
WithValue传递一个 trace ID，在多个函数中通过ctx.Value取出并打印，验证它跨函数、跨 goroutine 都能访问到。 - 用
WithCancelCause实现一个"失败即取消全部"的批量任务，用context.Cause打印出第一个失败原因。
相关推荐
2026-09-09
goroutine 与并发初探
需要预先了解： 函数 包与模块：代码组织 goroutine 与并发初探 Go 的并发能力从语言层面就开始了：一个 go 关键字就能启动一个 goroutine。这篇先讲清楚"并发"与"并行"的区别、goroutine 的启动与开销，再引出 sync.WaitGroup、sync.Once 这两个基础同步工具，最后给出 GMP 调度模型的概览，为后面几篇铺路。 并发与并行 先区分两个概念： 并发（concurrency）：多个任务在重叠的时间段内推进，宏观上"同时"发生，微观上可能是交替执行； 并行（parallelism）：多个任务在同一个时刻真正同时执行，需要多核支持。 并发是一种程序结构，并行是一种执行状态。一个程序可以并发但不并行（比如只给一个 CPU 核心）。 几个系统层面的执行单元： 概念 说明 进程 拥有独立地址空间的执行单元，进程之间默认不共享内存 线程 进程内的执行单元，共享进程的地址空间，由操作系统调度 协程 用户态的轻量执行单元，由语言运行时或库调度...
2026-09-09
并发设计模式与陷阱总结
需要预先了解： goroutine 与并发初探 channel sync 包与原子操作 context 并发设计模式与陷阱总结 前四篇讲了 goroutine、channel、同步原语和 context 的用法，这一篇把它们组织成可复用的模式，并把并发编程里最容易踩的坑集中列出来。 pipeline **pipeline（流水线）**把任务拆成若干阶段，每个阶段的输入输出都是 channel，数据像流水一样流过： // 生成器：产生数据 func gen(nums ...int) <-chan int { out := make(chan int) go func() { defer close(out) for _, n := range nums { out <- n } }() return out } // 阶段：处理数据 func square(in <-chan int) <-chan int { out ...
2026-09-09
sync 包与原子操作
需要预先了解： goroutine 与并发初探 channel sync 包与原子操作 多个 goroutine 同时读写同一份数据，如果不加保护，就会产生竞态条件（race condition）。这一篇讲清楚竞态是怎么发生的、怎么用 -race 检测它，以及 sync.Mutex、sync.RWMutex、sync/atomic、sync.Map、sync.Pool 各自的适用场景。 竞态条件 var counter int func main() { var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { defer wg.Done() counter++ }() } wg.Wait() fmt.Println("counter =", counter) } 期望值是 1000，实际运行可能得到： counter = 968 原因在于 counter++ ...
2026-09-09
channel
需要预先了解： goroutine 与并发初探 channel channel 是 goroutine 之间传递数据的管道，也是 Go 并发模型的核心。它同时承担两件事：传递数据和同步。这一篇讲清楚无缓冲与有缓冲的差别、close 的规则、select 的多路复用，以及几个会让程序直接崩溃的操作。 设计哲学 Go 的并发信条是： 不要通过共享内存来通信，而要通过通信来共享内存。 意思是：与其让多个 goroutine 抢着读写同一块内存（然后用锁保护），不如让数据在 goroutine 之间传过来，同一时刻只有一方持有它。channel 就是传递的载体。 无缓冲 channel：同步语义 make(chan T) 创建的是无缓冲 channel。它的发送和接收必须同时就位才能完成——发送方会一直阻塞，直到有接收方来取： ch := make(chan int) go func() { fmt.Println("发送前") ch <- 1 fmt.Println("发送完成") }() time.Sleep(100 * ti...
2026-09-09
接口与 channel 的底层实现
需要预先了解： 接口 channel 内存分配与逃逸分析 接口与 channel 的底层实现 接口 里留下的 nil 陷阱、channel 里"收发是拷贝"的结论，都可以从运行时结构上得到解释。这一篇看 eface/iface/itab 和 hchan 的真实字段，以及一次发送、一次接收、一次关闭在底层分别发生了什么。 eface 与 iface 空接口和非空接口在运行时是两种结构： type eface struct { // 空接口 any / interface{} _type *_type // 动态类型 data unsafe.Pointer // 指向动态值的指针 } type iface struct { // 带方法的接口 tab *itab // 类型 + 方法表 data unsafe.Pointer // 指向动态值的指针 } 两者都是两个指针宽，在 64 位平台上是 16...
2026-09-09
调度器：GMP 模型深入
需要预先了解： goroutine 与并发初探 channel 调度器：GMP 模型深入 goroutine 与并发初探 里给出了 GMP 的概览。这一篇展开内部结构：G 里存了什么、调度器怎么选下一个 G、work stealing 和 hand-off 如何工作、抢占是怎么实现的，以及为什么网络 IO 不会占住线程。 G、M、P 的职责 G G G G G = goroutine（任务：栈 + 状态 + 调度信息） | | | | v v v v +---------------+ P = 逻辑处理器（本地队列 + 资源配额） | P runq | +---------------+ | v +---------------+ M = 内核线程（真正执行指令） | M | +---------------+ 结构 内容 G 栈指...
