context.Context 通过层次树结构传播取消信号，每个衍生节点通过嵌入的 cancelCtx 或 valueCtx 结构保持对其父节点的引用。这个树结构可以实现双向跟踪：父节点通过一个受互斥锁保护的映射知道它的子节点，而子节点通过直接的指针引用知道它的父节点。当发生取消时，这种设计允许从根节点立即遍历到叶子节点，而无需全局协调。
当在父节点上调用 cancel() 时，它获取一个互斥锁来保护 children 映射，遍历所有注册的子上下文，并递归调用它们各自的 cancel 闭包。每个子节点的 cancel 函数关闭其自己专用的 done 通道（通过 sync.Once 懒加载以优化那些从未取消的上下文），并从父节点的 children 映射中移除自己，以消除本来会阻止垃圾回收的引用。这个机制确保了取消信号在整个子树中瞬间传播，同时避免资源泄漏。
对于基于超时的取消，timerCtx 嵌入了一个 time.Timer，当截止时间到期时会自动触发 cancel 闭包。至关重要的是，如果父节点在计时器触发之前取消，子节点的 cancel 函数会显式停止计时器，必要时排空通道，防止计时器的 goroutine 在运行时滞留并在上下文已经被取消后占用资源。
考虑一个高吞吐量的 Go 微服务处理用户请求，这些请求向三个下游服务扇出：一个主要的 PostgreSQL 数据库，一个 Redis 缓存，以及一个第三方 REST API。每个请求必须针对所有三个源执行查询以聚合响应，p99 延迟预算低于 500 毫秒。该服务处理数千个并发连接，因此资源管理对稳定性至关重要。
问题描述：
在高负载下，客户端在提交请求后频繁断开连接（超时或关闭连接），但 goroutines 继续处理完整的数据库查询并等待缓慢的外部 API，耗尽连接池和 CPU，尽管结果毫无价值。手动取消需要在数十个函数调用中传递布尔标志，这既脆弱又容易出错。此外，如果没有适当的传播，处理这些被遗弃请求的 goroutines 可能会无限积累，最终导致主机服务器的 OOM（内存溢出）状况或文件描述符耗尽。
考虑的不同解决方案：
手动传播与原子标志： 我们考虑过在每个函数签名中传递一个 atomic.Bool 指针，定期在循环中检查它。这种方法没有抽象开销，并提供了对取消点的显式控制。然而，它无法中断阻塞的系统调用，例如 TCP 读取，需要对每个库函数进行大规模代码修改，并且没有标准化的超时或截止日期。
使用显式杀死通道的 goroutine 农场： 在单独的 goroutine 中启动每个下游操作，并在自定义关闭通道上使用 select 块允许在请求取消时提前返回。这种方法提供了非阻塞的取消点，并为每个操作提供了模块化的超时处理。然而，这为每个请求创建了 O(n) 的 goroutines，其中 n 是操作的数量，带来了显著的调度开销，并且仍然无法强制在不接受通道或检查取消状态的第三方库内部进行取消。
标准上下文树传播： 利用 http.Request.Context() 作为根，并通过 context.WithTimeout 为每个下游调用派生子上下文，允许在标准库中本地支持取消。这种方法提供了截止日期通过整个调用栈的自动传播，而每个操作没有 goroutine 的额外开销，并自动处理计时器清理。然而，它要求严格遵守正确的 API 使用方式，例如始终调用 WithTimeout 返回的取消函数，以避免泄漏计时器资源。
选择的解决方案和结果：
我们选择了标准的上下文树传播，每个 HTTP 处理程序派生一个具有 30 秒超时的请求范围上下文，单独的数据库查询使用 context.WithTimeout(reqCtx, 2*time.Second) 强制更严格的子截止日期。当客户端断开连接时，HTTP 服务器取消根上下文，该上下文遍历树结构，立即解锁 sql 驱动程序的网络调用以释放连接。在进行 10k 个并发请求和 30% 客户端掉线的负载测试中，连接池耗尽事件减少了 95%，由于减少了资源争用，活跃请求的 p99 延迟显著改善。
为什么被取消的子上下文必须显式地从其父上下文的 children 映射中移除以防止内存泄漏？
许多人认为父上下文会保留子上下文，直到它本身被销毁。实际上，当 cancelCtx.cancel() 运行时（无论是来自父传播还是本地超时），它获取父上下文的互斥锁并从 children 映射中删除自己。如果没有进行此移除，长期存在的父上下文（如后台服务器上下文）将为每个创建的瞬态请求上下文积累条目，阻止已经完成的请求内存的垃圾回收，并导致堆的无限增长。
context.WithValue 如何在保持 O(k) 查找时间的同时，为每个键实现 O(1) 空间，其中 k 是树的深度，以及为什么不使用映射？
候选人经常建议在每个 WithValue 调用时复制映射（这会导致映射大小为 O(n)）或使用全局同步映射（并发问题）。实际上实现使用链表：每个 valueCtx 包含一个键、值和父指针。Value() 向上遍历以比较键。由于上下文树通常不超过 5-10 层（请求 → 处理程序 → 服务 → 数据库 → 事务），这在效能上是常数时间。为每个上下文使用一个映射要么需要复制（代价高昂），要么需要可变性（在并发读取中不安全）。
在 context.Context 接口变量中存储 nil 的特定危险是什么，以及为什么 context.Background() 返回一个非 nil 的空结构而不是 nil？
虽然 var c context.Context = nil 是有效的，但将其传递给期望可取消上下文的函数时会导致在 nil 接口上调用方法时出现恐慌。Background() 返回一个单例 backgroundCtx{}（一个实现了接口的非 nil 空结构），以确保方法调用始终成功，并提供上下文树的稳定根。这避免了 "nil 接口 vs nil 具体" 的混淆（在此情况下，类型为 nil 的指针通过 != nil 检查，但在调用方法时会出现恐慌），从而确保上下文值永远不为 nil，只有它的父指针可能在逻辑上为 nil。