WithCancel 是手动触发取消的上下文，返回可调用 cancel() 的 ctx，调用后所有子 ctx 立即取消；需避免漏调或冗余调用，适用于响应用户操作、信号或业务判断。
WithCancel 是手动触发取消的上下文
当你需要在某个条件满足时主动终止子 goroutine 或清理资源，context.WithCancel 是最直接的选择。它返回一个可手动调用 cancel() 函数的上下文，一旦调用，所有基于它的子上下文都会立即收到取消信号。
常见错误是忘记调用 cancel()，导致 goroutine 泄漏或资源未释放；或者在多个地方重复调用 cancel()（虽然安全，但没必要）。
-
cancel()可被多次调用，后续调用无副作用 - 适合响应用户操作、外部信号（如
os.Signal）、或业务逻辑判断（如重试失败后主动退出） - 不带时间语义，完全依赖程序逻辑控制生命周期
ctx, cancel := context.WithCancel(context.Background())
go func() {
select {
case <-ctx.Done():
fmt.Println("canceled")
}
}()
cancel() // 主动触发WithTimeout 是带自动超时的 WithCancel
context.WithTimeout 本质是 context.WithDeadline 的封装，它在指定持续时间后自动调用 cancel()。换句话说：它 = WithCancel + 定时器。
容易踩的坑是误以为超时只影响当前 goroutine —— 实际上，超时会传播到所有子上下文，且 ctx.Err() 会返回 context.DeadlineExceeded，不是 context.Canceled。
立即学习“go语言免费学习笔记（深入）”；
- 超时时间从调用
WithTimeout那一刻开始计时，和系统时钟无关 - 如果提前手动调用
cancel()，超时定时器会被停止，不会泄漏 - 注意：传入负数或零值会导致立即超时（
ctx.Err() == context.DeadlineExceeded）
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel() // 仍建议 defer，防止 panic 跳过
select {
case <-time.After(3 * time.Second):
fmt.Println("slow")
case <-ctx.Done():
fmt.Println(ctx.Err()) // context.DeadlineExceeded
}WithTimeout 和 WithDeadline 的关键区别
很多人混淆 WithTimeout 和 WithDeadline。前者接受 time.Duration，后者接受绝对时间点 time.Time。这意味着：
- 网络请求类场景（比如“最多等 5 秒”）优先用
WithTimeout - 与外部系统约定截止时间（如“必须在 2024-10-01T12:00:00Z 前返回”）才用
WithDeadline -
WithTimeout(d)等价于WithDeadline(time.Now().Add(d))，但不要手动这样写 —— 时钟偏移或纳秒级误差可能导致行为不一致
取消信号传播不是立刻中断运行
Context 的取消只是通知机制， 收到信号后，goroutine 需要自行检查并退出。Go 不会强制终止正在运行的函数。
这意味着：如果某个函数阻塞在系统调用（如 http.Client.Do、time.Sleep、未缓冲 channel 操作）上，它可能无法及时响应取消 —— 必须依赖该操作本身对 ctx 的支持（例如 http.NewRequestWithContext）。
- 原生阻塞操作（如
time.Sleep）需配合select+ctx.Done()手动退出 - 第三方库是否尊重 context，得看它是否显式接收并使用
ctx参数 - 长时间 CPU 密集型计算中，需定期检查
ctx.Err() != nil，否则永远收不到取消信号
