调用 cancel() 后 goroutine 不会自动退出，必须主动监听 ctx.Done() 并响应；cancel() 仅关闭 Done() 通道，goroutine 是否退出取决于是否在 select 中处理该信号。
调用 cancel() 后，所有监听该 ctx.Done() 的 goroutine 不会自动退出，必须主动检查并响应信号——这是最常被忽略的前提。
为什么 cancel() 调用了但 goroutine 还在跑
根本原因不是 context.WithCancel() 失效，而是 goroutine 没有监听 ctx.Done() 或没做退出处理。Go 协程不会被强制终止，cancel() 只是关闭一个 chan struct{}，后续行为完全取决于你代码里有没有 select 块去接收它。
- 常见错误：只传了
ctx进 goroutine，但循环里没写case - 更隐蔽的问题：阻塞在
http.Client.Do()、time.Sleep()或io.Read()等调用上，而这些函数本身支持ctx参数——但你没传进去 - 注意：
ctx.Done()关闭后，select会立即走该分支；但如果 goroutine 正卡在不响应 ctx 的系统调用里（比如裸time.Sleep(10*time.Second)），它就收不到信号
context.WithCancel() 的父子传播规则
子 context 的取消只由两件事触发：父 context 被 cancel，或自己对应的 cancel() 被调用。反过来，子 context 的 cancel 不会影响父 context，也不会影响兄弟 context。
- 正确用法：
ctx, cancel := context.WithCancel(parentCtx)，然后把ctx传给下游 goroutine，cancel留在当前作用域控制 - 错误模式：多个 goroutine 共享同一个
cancel函数并发调用——虽然cancel()是幂等的，但可能造成逻辑混乱（比如 A 任务刚完成就调了cancel()，B 任务还没开始就被中断） - 典型场景：HTTP handler 中派生子 context 给数据库查询和第三方 API 调用，主 handler 结束时调
cancel()，确保下游调用能及时中止
必须搭配 defer cancel() 吗
不是“必须”，但不 defer 极大概率导致 context 泄漏。泄漏的 context 会一直持有其 done channel 和内部引用，如果它派生了大量子 context 或绑定了大量 WithValue 数据，内存不会释放。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 适用
defer cancel()的场景：函数级生命周期明确，比如 handler 函数、RPC 方法入口 - 不能 defer 的情况：需要长期存活的后台任务（如定时同步），此时
cancel()应由外部信号（如 signal.Notify、管理接口）触发 - 关键点：
cancel()调用后，该 context 的Err()会返回context.Canceled，且Done()返回的 channel 已关闭——后续再调cancel()无副作用，但也不该重复调用
和 WithTimeout / WithDeadline 混用时的优先级
cancel() 和超时是“或”关系：任意一个触发，ctx.Done() 就关闭。手动调 cancel() 会立即生效，不受 timeout 倒计时约束；超时到达也会自动 cancel，无需你干预。
- 推荐组合：
ctx, cancel := context.WithTimeout(parent, 5*time.Second)，再在必要时提前cancel()（比如用户主动取消请求） - 陷阱：
WithTimeout返回的cancel函数也必须调用，否则 timer 不会释放——即使超时已触发，仍需defer cancel() - 验证方式：打印
ctx.Err()，如果是context.DeadlineExceeded说明是超时触发；context.Canceled则是手动 cancel 触发
真正难的不是调 cancel()，而是让每个 goroutine 都在恰当位置检查 ctx.Done()，并在退出前清理资源（比如关闭文件、释放锁、回滚事务）。这需要把 context 当作函数签名的一部分来设计，而不是事后补丁。
