context 不用于启动并发，而是传递取消信号、超时和请求数据；withcancel 仅返回可监听的 done channel 和关闭它的 cancel 函数，goroutine 必须显式检查 done() 并自行退出。
Go 语言中，context 不是用来“启动”并发任务的，而是用来**传递取消信号、超时控制和跨 goroutine 的请求作用域数据**。真正启动并发的是 go 语句，context 只负责在任务运行中干预其生命周期。
为什么直接用 context.WithCancel 后不调用 cancel() 就没效果
这是最常见误解：以为创建了带 cancel 的 context 就自动具备终止能力。其实 context 本身不执行任何取消逻辑，它只提供一个可监听的 Done() channel；你必须在 goroutine 内部主动检查这个 channel，并自行退出。
-
context.WithCancel返回一个context.Context和一个cancel函数，后者只是关闭内部donechannel - 所有依赖该 context 的 goroutine 必须显式读取
<ctx>.Done()</ctx>或用select等待它 - 如果 goroutine 里没做任何响应（比如阻塞在无缓冲 channel 上且没加
default或case ），那 cancel 就完全失效
示例错误写法：
ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
go func() {
time.Sleep(200 * time.Millisecond) // 完全忽略 ctx，cancel 调了也白调
fmt.Println("done")
}()
cancel() // 这里调了，但上面 goroutine 不感知
如何让 HTTP 请求真正响应 context 超时
标准库 http.Client 支持传入 context.Context，但它只控制请求发起阶段的等待（如 DNS 解析、连接建立、首字节响应时间），**不强制中断已建立的 TCP 连接或正在读取的响应体**。要完整中断，需配合 http.Transport 的底层设置。
立即学习“go语言免费学习笔记（深入）”；
- 使用
client.Do(req.WithContext(ctx))是基础，但仅保证请求不会“无限挂起”在发起环节 - 若响应体很大或服务端流式返回慢，需额外设置
Transport.ResponseHeaderTimeout和Transport.ReadTimeout - 更可靠的做法是用
io.LimitReader(resp.Body, maxBytes)防止读取失控，再配合ctx.Done()做双重防护
关键点：HTTP 层的 context 控制是分阶段的，不是“一键熔断”。
在 select 中混用 ctx.Done() 和其他 channel 时的常见陷阱
当多个 channel 同时参与 select，而其中一个是 ctx.Done()，容易因 channel 关闭顺序或未读数据导致 goroutine 意外阻塞或漏处理。
-
ctx.Done()关闭后，再次读取会立即返回零值（nil error）——但如果你在select外还单独读了一次，就可能提前消费掉信号 - 不要在
select的default分支里做耗时操作，否则会掩盖ctx.Done()的及时响应 - 若其他 channel 可能持续发数据（如日志 channel），而你又想优先响应取消，应把
放在 <code>select的第一个case（虽然 Go 不保证顺序，但习惯上如此提高可读性）
正确模式示例：
select {
case <-ctx.Done():
return ctx.Err() // 立即退出
case data := <-ch:
process(data)
}
子 context 的派生与取消传播不是自动“级联”的
context.WithCancel、WithTimeout、WithValue 创建的子 context，其取消行为取决于父 context 是否被取消，以及子 context 自身是否设置了独立超时。但父子之间没有“继承式取消”，只有“信号广播”。
- 父 context 被 cancel → 所有直系子 context 的
Done()同时关闭 - 子 context 设置了
WithTimeout→ 到期后自己关闭Done()，不影响父或其他兄弟 context -
WithValue创建的 context 永远不会被 cancel，除非它的父被 cancel —— 它只是个“只读数据携带者” - 切忌在子 context 上反复调用
WithValue构建深层嵌套，value 查找是 O(n)，且易造成内存泄漏（value 引用大对象）
真正难调试的，往往是多个 goroutine 共享同一个 context，但部分 goroutine 忘记监听 Done()，导致整个请求无法释放资源。这种问题不会报错，只会悄悄拖慢系统。
