context.withtimeout需配对使用ctx和cancel，否则导致goroutine或timer泄漏；http超时应优先用http.client.timeout；子context取消信号同步通知直接子级，不自动传播至孙子级。
context.WithTimeout 用法和典型误用
超时控制不是加个 context.WithTimeout 就完事——它返回的 ctx 和 cancel 必须配对使用，否则可能泄露 goroutine 或 timer。常见错误是只取 ctx 忽略 cancel，尤其在函数提前 return 时没调用 cancel()。
正确做法是：用 defer cancel() 包裹整个逻辑块；如果中间有多个出口（比如 error 分支、early return），必须确保每个出口前都调用 cancel()，或统一 defer。
-
context.WithTimeout底层启动一个time.Timer，不调用cancel()就不会停，timer 会一直占资源直到触发 - 超时时间从调用
WithTimeout那一刻开始计，不是从后续操作开始算 - 如果只是想限制某次 HTTP 请求，优先用
http.Client.Timeout，比手动套context更直接且不易出错
HTTP 请求里 context 超时为什么有时不生效
根本原因：底层 net.Conn 没有响应 context 取消信号。比如 http.Get 在 DNS 解析、TCP 连接建立、TLS 握手阶段卡住时，context 默认无法中断这些系统调用（尤其在 Windows 或老版本 Go）。
解决方案取决于场景：
立即学习“go语言免费学习笔记（深入）”；
- Go 1.19+：启用
GODEBUG=netdns=cgo可让 DNS 解析响应 cancel（但依赖 cgo） - 更可靠的是设置
http.Client的各阶段超时字段：Timeout、Transport.DialContext、Transport.TLSHandshakeTimeout - 不要指望
context.WithTimeout单独解决所有网络阻塞——它只保证http.Do返回后能及时退出，不保证“立刻断开正在建连的 socket”
子 context 的 cancel 传播规则
context.CancelFunc 调用后，取消信号会**立即同步**通知所有直接基于该 context 派生的子 context（包括 WithCancel、WithTimeout、WithValue），但不会自动传播到“孙子级”以下，除非它们也监听了父级 Done()。
关键点：
- 子 context 的
Done()channel 会在父 cancel 后立刻关闭，无需轮询 -
context.WithValue创建的 context 不带取消能力，不能被 cancel，只能靠上游传递取消信号 - 多个 goroutine 共享同一个
ctx是安全的，但共享cancel函数不安全——同一时间只能由一个 goroutine 调用它
测试中模拟 context 超时失败的常见写法
写单元测试时，用 context.WithTimeout(ctx, 1*time.Nanosecond) 并不可靠：Go 调度和 timer 精度可能导致实际未触发超时就执行完了，测试偶然通过。
真正可控的做法是用 context.WithCancel + 手动 close channel：
ctx, cancel := context.WithCancel(context.Background())
go func() {
time.Sleep(10 * time.Millisecond)
cancel() // 主动触发
}()
// 然后传 ctx 给待测函数或者用 testhelper 类工具（如 github.com/fortytw2/leaktest）辅助验证 goroutine 是否残留，因为超时漏 cancel 最难 debug 的就是资源泄漏。
别忘了：生产代码里 context 是传递取消信号的载体，不是替代具体 I/O 超时配置的万能开关。越靠近底层操作（比如数据库驱动、自定义 net.Conn），越要查清它是否真支持 context 取消——很多老库只读 Done() 但不主动响应。
