为什么Golang的context.WithCancel返回取消函数而非Context内置Cancel方法

这种设计和函数式编程范式没有关系，核心是出于权限控制和接口封装的考量，主要原因如下：

• 接口隔离，避免下游随意篡改上下文生命周期
  Context 接口本身的定义仅包含只读类方法（取值、判断是否结束、获取通知通道），完全没有设计修改类方法。如果给 cancelCtx 增加公开的 Cancel() 方法，要么需要把该方法加入 Context 接口定义——这会导致所有拿到 Context 实例的调用方（包括调用链下游的子函数、第三方依赖）都可以随意取消上下文，上层逻辑的生命周期会被下游意外破坏，完全不符合 Context 的设计原则：Context 的取消权只会交给创建它的上层代码持有。
  要么不把 Cancel() 加入 Context 接口，但 cancelCtx 本身是 context 包的私有类型，外部代码拿到的返回值永远是 Context 接口类型，根本没法断言到私有类型调用额外方法，加了等于白加。
• 封装内部实现，保证兼容性
  cancelCtx 是 context 包的内部实现类型，从来没有对外暴露的计划。返回闭包形式的取消函数，相当于把取消操作封装成了一个不透明的执行入口：外部只需要知道调用这个函数就能取消对应上下文，不需要了解任何内部实现细节。后续 Go 官方如果要修改取消逻辑、新增额外的清理操作，直接修改闭包的实现即可，完全不会影响上层用户的使用，兼容性更好。
  同时返回的闭包天然是幂等的，重复调用也不会出问题，这些逻辑都被封装在闭包里，用户不需要额外处理。
• 简化使用逻辑，避免错配
  返回的 cancel 函数是闭包，天然持有对应 cancelCtx 实例的引用，用户不需要额外维护上下文实例和取消方法的对应关系，只要遵循通用的最佳实践即可：

ctx, cancel := context.WithCancel(parentCtx)
defer cancel()
// 后续逻辑使用ctx

完全不会出现上下文和取消方法错配的问题，使用门槛更低。

内容的提问来源于stack exchange，提问作者Bing Xuan Ho