go context取消靠关闭done()通道触发监听方主动退出；父子context取消可穿透多层，但需正确派生且未被中间cancel()截断；子context不响应父取消，主因是子goroutine未监听ctx.done()，如只单次检查ctx.err()或select漏case。
Go context 的取消不是“发个命令就停”，而是靠 Done() 通道关闭触发监听方主动退出；父子 context 之间取消信号能穿透多层，但前提是每层都正确派生、没被中间 cancel() 提前截断。
为什么子 context 没响应父级取消？
绝大多数情况不是传播失败，而是子 goroutine 根本没在监听 ctx.Done()。
- 写了
if ctx.Err() != nil却只检查一次 → 循环里没放进去，后续取消收不到 - 用了
select，但漏了case ，或其它 case 永远阻塞（比如 <code>case data := 而 ch 已关但没 default） - goroutine 启动时传的是
context.Background()或旧 context，压根没接入链路 - HTTP handler 里启新 goroutine，却没把
r.Context()传进去，而是用了context.Background()
WithCancel 嵌套多层会断链吗？
不会断。Go context 的父子链由底层 cancelCtx 结构体维护双向引用，只要子 context 是从父 context 正确派生（如 context.WithCancel(parent)），取消就会穿透全部层级。
- 中间某层自己调过
cancel()→ 它的Done()已关闭，之后派生的子 context 不再响应更上层的 cancel（channel 无法二次关闭） -
context.WithValue包裹WithCancel派生的 context → 不影响取消链，WithValue只是装饰 - 验证是否链路完整：在子 goroutine 里打印
ctx.Err()，父级cancel()后应立刻变为context.Canceled，不是一直为nil
cancel() 该在哪儿调、什么时候调？
cancel() 必须由创建 context 的那一方显式调用，且只调一次；调早了下游还没干活就被砍，调晚了资源就泄漏。
- HTTP handler 中：在写完响应、或明确失败后立即调，别
defer到函数末尾（可能提前return） - 循环中反复创建
WithCancel：每次都要配对调cancel()，否则 timer 和 goroutine 会累积泄漏 - 把
cancel函数传进 goroutine 是危险操作 —— 很容易被误调或重复调；推荐用闭包封装，或由启动方统一控制
第三方库不支持 context 怎么办？
不能硬塞 ctx，得看情况处理：
- 查文档确认是否隐藏支持：有些库虽没暴露
ctx参数，但内部用了标准库（如http.DefaultClient），此时需手动替换为带 context 的实例 - 完全无取消能力（如纯计算、阻塞式 Cgo）：只能靠外部信号 + 协作退出 —— 启 goroutine 包裹调用，并在外部用
ctx.Done()触发中断逻辑（如关依赖 channel、设标志位、调Stop()） - HTTP 类 SDK：必须用
http.NewRequestWithContext；若提供.WithContext(ctx)链式方法，优先用它 - 数据库驱动：必须用
QueryContext/ExecContext，而不是Query/Exec；事务内也要用tx.QueryContext - 永远不要把
cancel交给不可控第三方代码 —— 它没调、忘了调、或调错时机，子 context 就永远卡住
真正难的从来不是怎么写 WithCancel，而是判断哪些 goroutine 必须接入取消链、在哪插 select、哪些阻塞调用必须换为 context-aware 版本、以及 cancel 后要不要关文件、释放锁、重置状态 —— 这些地方一漏，context 就只是个空壳。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
