Go协程控制中基于Context生命周期感知的主动断开函数设计

context.WithCancel不能直接终止goroutine，仅通过关闭Done通道发送取消信号；子协程必须主动监听ctx.Done()并自行退出，否则无法响应取消、释放资源或中断阻塞操作。

context.WithCancel 是唯一能让你在运行时主动触发协程退出的原生机制，它不杀协程，只发信号；你必须在子协程里监听 ctx.Done() 并自行退出。

为什么不能直接用 cancel() 就完事？

调用 cancel() 只是关闭 ctx.Done() 通道，它本身不做任何清理、不中断阻塞调用（比如 http.Get、time.Sleep、io.Read），也不保证子协程立刻停止。
子协程是否响应、何时退出、是否释放资源，全取决于你有没有在合适位置检查 ctx.Done() 并做对应处理。
常见错误现象：
– 协程仍在后台打印日志或发请求，但主逻辑已认为“已取消”
– http.Client 未传入 context，导致超时/取消信号被忽略
– 在非 select 块中轮询 ctx.Err() == context.Canceled，效率低且易漏判

context.WithCancel 的正确使用姿势

核心原则：每个派生出的 context.Context 都应有明确的生命周期归属，并由创建者负责调用 cancel()。
– 必须用 defer cancel() 包裹在创建它的函数末尾（除非你明确需要延迟取消）
– 不要把 cancel 函数暴露给下游协程，否则可能被误调或重复调用
– 若需跨 goroutine 触发取消，把 cancel 存为局部变量或闭包捕获，而非全局或结构体字段
– 启动子协程时，务必把 ctx 作为第一个参数传入，不要依赖闭包捕获外部 ctx

阻塞操作怎么配合 ctx.Done()？

Go 标准库多数 I/O 接口支持 context，但不是所有地方都自动感知：
– http.NewRequestWithContext(ctx, ...) → http.DefaultClient.Do(req) 才会响应取消
– time.Sleep 不接受 context，得改用 time.AfterFunc 或 select + time.After
– net.Conn 没有 context 参数，但 conn.SetDeadline 可配合 ctx.Deadline() 手动设置
– 自定义 long-running loop 必须用 select，且 case 要放在 default 前（避免忙等）<br>
示例片段：

func worker(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            log.Println("worker exiting:", ctx.Err())
            return
        default:
            // do work
            time.Sleep(100 * time.Millisecond)
        }
    }
}

容易被忽略的泄漏点

context 泄漏往往不是因为没调 cancel()，而是调得太晚或根本没调：
– 在 goroutine 内部调用 context.WithCancel，却没在 goroutine 退出前调 cancel()
– 把 ctx 传给第三方库后，丢失了对 cancel 的控制权
– 多层派生 context（如 WithValue → WithCancel → WithTimeout），只 cancel 最外层，内层仍存活
– HTTP handler 中用 req.Context() 派生新 context，但没在 handler 返回前调 cancel()（虽然通常由 net/http 自动处理，但自定义中间件时易出错）

真正难的不是写 cancel()，是判断“现在该不该取消”以及“取消后资源是否已释放”。ctx.Err() 返回值只有两个有意义状态：context.Canceled 和 context.DeadlineExceeded，其余都是 nil 或空，别靠它做业务分支。