context.WithTimeout需配合支持context的函数使用，否则超时无效；必须调用cancel释放资源；超时从调用时刻起计，非请求发起时；不可复用同一ctx于多请求；HTTP超时需协调context、Client.Timeout与Transport各层设置。
context.WithTimeout 用法和典型误用
超时控制不是加个 context.WithTimeout 就完事——它必须传给真正支持 context 的函数，否则只是空转。比如你用 http.Client 发请求，得确保 client 的 Do 方法接收的是带超时的 context；如果自己手写阻塞型 I/O（如 time.Sleep 或未封装的 socket read），不主动检查 ctx.Done()，超时根本不会生效。
常见错误现象：context.DeadlineExceeded 没触发、goroutine 泄漏、HTTP 请求卡住远超设定时间。
-
context.WithTimeout返回的context.Context和cancel函数必须成对使用：不用时调用cancel()，否则底层 timer 不释放，长期运行服务会累积 goroutine - 超时时间从
WithTimeout调用那一刻开始计时，不是从请求发出那一刻——如果中间有耗时初始化（如 DNS 解析、连接池等待），实际可用的网络处理时间会少于设定值 - 不要把同一个
ctx复用到多个独立请求中：一个请求提前超时会 cancel 整个 context，连带影响其他还在跑的请求
http.Client 设置 Timeout 的三层控制关系
Go 的 HTTP 超时不是单点配置，而是 context + client + transport 三者叠加生效。最容易踩的坑是只设了 context.WithTimeout，却忽略了 http.Client.Timeout 或 http.Transport 的底层限制，结果被更早的底层 timeout 截断，还查不到原因。
典型场景：你设了 5 秒 context 超时，但 http.Transport.DialContext 默认有 30 秒连接建立上限，这时超时表现是 net/http: request canceled (Client.Timeout exceeded while awaiting headers)，而非你预期的 context deadline exceeded。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
http.Client.Timeout是兜底总超时，覆盖整个请求周期（DNS + dial + write + read），优先级低于 context，但会强制中断已发起的底层操作 -
http.Transport可细粒度控制：DialContext控制建连、ResponseHeaderTimeout控制 header 到达、IdleConnTimeout影响复用连接——这些值若小于 context 超时，就会先触发 - 真正推荐的做法：关闭
http.Client.Timeout（设为 0），只靠 context 控制；同时确保Transport各项 timeout ≥ context 超时，避免干扰
自定义函数如何正确响应 context 取消
不是所有 Go 函数都原生支持 context。如果你封装了数据库查询、文件读取或调用第三方 SDK，而它们没暴露 context.Context 参数，就不能指望 context.WithTimeout 自动生效。必须手动轮询 ctx.Done() 并提前退出。
常见错误现象：函数内部用 for {} 等待某个条件，但没在每次循环里 select ctx.Done()，导致 timeout 后仍死等。
- 任何可能阻塞的操作前，都该加
select判断：select { case <-ctx.Done(): return ctx.Err() default: } - 调用不支持 context 的同步函数（如
os.ReadFile）时，无法中途取消，只能靠启动 goroutine + channel +select包裹，但要注意资源清理（比如文件句柄不能泄露） - 慎用
ctx.Value传递超时时间：它不参与取消逻辑，只是透传数据；超时控制必须依赖ctx.Done()通道
测试 context 超时是否真起作用
本地跑一次没超时，不代表线上不出问题。很多超时逻辑只在高延迟、弱网或服务端 hang 住时才暴露。不验证，等于没写。
关键点在于：不能只测「正常路径」，要模拟 ctx.Done() 被关闭的瞬间行为，尤其是资源是否释放、error 是否返回预期类型。
- 用
context.WithCancel+ 手动cancel()替代WithTimeout，精确控制触发时机，避免依赖真实时间等待 - 检查返回 error 是否为
context.Canceled或context.DeadlineExceeded，而不是笼统的err != nil - 并发压测时观察 goroutine 数量：超时后 goroutine 应快速归零；若持续增长，说明有 goroutine 卡在未响应 cancel 的地方
