Go context.WithCancel 父 context 取消后子 context 会怎样

用 context.WithCancel 派生上下文时，取消关系是单向的：父 context 被取消，子 context 和它继续派生出的后代都会收到取消信号；子 context 被取消，不会反过来取消父 context，也不会影响兄弟 context。判断是否结束，应该观察 Done()，再用 Err() 区分原因。

父 context 取消时，子 context 为什么会一起结束

WithCancel(parent) 返回的是指向 parent 的派生 context，并为 child 创建新的 Done 通道。parent 的 Done 一旦关闭，child 的 Done 也会关闭；child 如果继续派生 grandchild，取消会继续向下传递。

这个关系可以看成一棵树，而不是一条可双向控制的链：

因此，HTTP 请求、数据库查询和 RPC 调用通常共享请求 context：请求结束后，上游取消可以让下游尽快停止等待。但“尽快”取决于下游是否真正读取 Done，或是否把 ctx 传给支持 Context 的 API。

用 Done 和 Err 判断到底是谁取消了

只看 Done 只能知道 context 已经结束，不能说明是主动取消还是截止时间到了。Err 通常返回 context.Canceled 或 context.DeadlineExceeded。下面的示例专门演示传播关系，打印顺序不作为并发时序保证：

package main

import (
    "context"
    "fmt"
)

func main() {
    parent, cancelParent := context.WithCancel(context.Background())
    child, cancelChild := context.WithCancel(parent)
    defer cancelParent() // 兜底释放 parent 及其子树的关联资源
    defer cancelChild()  // 即使提前返回，也要释放 child 的关联资源

    cancelChild() // 只取消 child，不会取消 parent
    

示例中 child 的 Done 会关闭，child.Err() 是 context.Canceled，而 parent 仍未取消。若把 cancelChild() 换成 cancelParent()，两个 context 都会结束，且 child 的错误也会反映取消原因。

子 context 取消不会反向影响父 context

这种单向性是设计出来的：一个子任务失败或提前完成时，可以结束自己的工作，却不应该擅自终止同一请求下的其他任务。需要“任意一个任务失败就取消全部任务”时，应由共同的上层持有 cancel 函数，再由上层统一做决定。

另一个常见误解是“调用 cancel 就会杀掉 goroutine”。实际上 cancel 只是关闭信号；worker 需要在循环、阻塞等待或下游调用处主动选择返回：

func worker(ctx context.Context, jobs 

写 WithCancel 时先检查这份清单

• 创建了 child，就在拥有它的函数中安排 defer cancel()，避免 child 因长期不取消而滞留。
• 下游函数把 ctx 作为第一个参数接收，不要把 context 藏进业务结构体。
• 循环和阻塞等待都要有退出分支；仅仅传入 ctx，不代表自定义计算会自动停止。
• 返回错误时保留 ctx.Err()，不要把取消伪装成普通业务失败。

相关问题

调用两次 cancel 会报错吗？

不会。CancelFunc 可以重复调用，后续调用没有额外效果；这也是把它放进 defer 做兜底的原因。

父 context 有超时，子 context 会返回什么？

父级因截止时间结束时，子级也会结束，通常可通过 Err() 看到 context.DeadlineExceeded；如果是显式调用 cancel，则通常是 context.Canceled。

怎样让一个子任务取消所有并行任务？

让并行任务共享同一个上层派生 context，由协调者持有 cancel 函数，在检测到失败后取消这个共同父节点，而不是让某个 worker 直接操作别人的 context。