Go context取消函数传递是否有问题？context包使用最佳实践有哪些？

你示例代码中function1的cancel操作未触发父context的Done通道，是因为function1内部调用context.WithCancel(ctx)时，是基于传入的父context派生了一个全新的子context，返回的cancel函数只会取消这个子context及其下游派生的context，完全不会影响传入的父context，这是context取消的层级传播规则：取消信号只会从上到下传递，子context的取消不会向上影响父context。

传递context取消函数确实存在风险，原博客的观点是符合官方设计意图的：

你可以按需传递cancel函数，但这一做法非常不推荐。这会导致cancel的调用方无法意识到取消该context可能带来的下游影响：可能存在多个从该context派生的其他context，会引发程序出现非预期行为。简而言之，绝对不要传递cancel函数。

风险具体体现在几个方面：

• 分散了cancel函数的控制权，原本持有cancel的创建方无法管控取消时机，下游任意调用方的误操作都会导致整个链路的所有任务被强制终止，排查问题难度极高
• 调用方无法感知当前context的派生链路，不知道一次cancel会影响多少下游goroutine、多少业务逻辑，很容易引发预期外的雪崩
• 违反了context的分层设计原则，context的取消信号本应是从上向下传递，传递cancel相当于允许下游反向控制上游的生命周期，会导致整个链路的生命周期管理完全混乱

当然并非100%不能传递，仅在你完全可控的内部逻辑场景下可以有限传递，且必须通过代码注释明确约定调用规则、禁止二次向下传递。

context取消函数的最佳实践 #

• 遵循cancel所有权原则：谁通过context.WithCancel/context.WithTimeout/context.WithDeadline创建派生context，谁就持有对应的cancel函数所有权，默认不对外传递，由创建方负责调用cancel
• 必须调用cancel：所有派生context对应的cancel函数必须被调用，无论任务成功还是失败，避免goroutine和内存泄漏，通常创建后直接声明defer cancel()即可
• 下游不要修改上游context的生命周期：如果下游逻辑需要独立的取消控制，应该基于传入的父context派生新的子context，持有自己的cancel函数，子context的取消只会影响当前分支的下游，不会干扰父context和其他兄弟分支
• context作为函数第一个参数传递：所有需要受取消控制的函数，统一将context.Context作为第一个参数传递，不要在结构体中存储context（长生命周期实例需要统一链路控制的场景除外，必须加明确注释说明）
• 不要用context传递业务参数：context仅用于传递请求链路的取消信号、超时控制、跨链路元数据，不要作为通用参数容器传递业务可选参数，避免逻辑混乱

如果你需要在下游逻辑中触发父级context的取消，不要通过传递cancel实现，更合理的做法是将触发条件作为独立的信号通道传递，或者由父级持有cancel的逻辑监听对应的状态自行触发取消。

内容的提问来源于stack exchange，提问作者Jorge Carvajal