context.WithTimeout 不自动终止 goroutine，仅关闭 ctx.Done()；需手动检查 ctx.Err() 或用 select 监听。WithDeadline 用于绝对时间，WithTimeout 用于相对时长，后者更安全清晰。
context.WithTimeout 为什么没让 goroutine 提前退出
根本原因：超时只影响 ctx.Done() 通道关闭，不自动终止正在运行的 goroutine。你得自己监听并退出。
- 常见错误现象：
context.WithTimeout设置了 100ms，但函数内部 sleep 200ms 后才返回，超时像没生效 - 正确做法：在关键阻塞点（如
http.Do、time.Sleep、循环中）检查ctx.Err() != nil，或用select等待ctx.Done() - 典型误用：
go func() { time.Sleep(200 * time.Millisecond); doWork() }()—— 这个 goroutine 完全无视 context - 性能影响：频繁调用
ctx.Err()几乎无开销；但若在 tight loop 中不加runtime.Gosched()，可能饿死其他 goroutine
Deadline 和 Timeout 到底该选哪个
看时间基准：绝对时间用 WithDeadline，相对时长用 WithTimeout。底层都转成 deadline，但语义和可维护性差很多。
- 使用场景：
WithDeadline适合“必须在 2024-06-15T14:30:00Z 前完成”的调度任务；WithTimeout更常见于 RPC 调用、DB 查询等“最多等 5s”场景 - 参数差异：
WithDeadline(ctx, time.Now().Add(5*time.Second))和WithTimeout(ctx, 5*time.Second)效果一致，但后者更清晰、不易因系统时间跳变出错 - 兼容性注意：如果父 context 已有 deadline，
WithTimeout新设的 timeout 可能被提前截断 —— 最终 deadline 是两者中更早的那个
HTTP client 里 context 不生效的三个硬坑
http.Client 确实支持 context，但只管请求发起阶段；DNS 解析、TLS 握手、TCP 连接建立这些底层环节，老版本 Go（
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见错误现象：设置 100ms timeout，但遇到 DNS 污染或服务端不响应时卡住 30s+
- Go 1.19+：启用
http.Transport.ForceAttemptHTTP2 = true并配合http.Transport.DialContext可提升 cancel 响应性；但 DNS 仍可能绕过（取决于net.Resolver实现） - Go 1.18 及更早：必须手动设置
http.Transport.DialContext+ 自定义net.Dialer.Timeout和KeepAlive，否则 timeout 对连接建立无效 - 真实示例：
client := &http.Client{<br> Transport: &http.Transport{<br> DialContext: (&net.Dialer{<br> Timeout: 3 * time.Second,<br> KeepAlive: 30 * time.Second,<br> }).DialContext,<br> },<br>}
子 context 的 cancel 必须显式调用
context.WithCancel、WithTimeout、WithDeadline 返回的 cancel 函数，不调就永远不释放资源 —— 这是内存泄漏最隐蔽的来源之一。
立即学习“go语言免费学习笔记（深入）”；
- 容易踩的坑：在 defer 中写
defer cancel()，但函数提前 return 了，cancel 没执行；或者 panic 后 recover 但忘了 cancel - 最佳实践：所有
WithXXX调用后，确保对应 cancel 在作用域结束前被执行；HTTP handler 中常放在函数末尾 defer，但要确认路径全覆盖 - 调试技巧：启动时加
GODEBUG=goroutines=2或用 pprof 查看 goroutine 数量突增，常能暴露漏掉的 cancel - 性能影响：每个未 cancel 的 context 会维持一个 goroutine 监听 done channel，长期积累直接拖垮调度器
事情说清了就结束。真正难的不是写对那几行 context 代码，而是想清楚——这个 timeout 到底是对谁生效、在哪一环起作用、失败后谁来清理、清理是否彻底。
