会，context.WithTimeout 在超时到达时自动触发内部 cancel 函数，关闭 ctx.Done()、停止 timer 并释放资源；但必须显式调用 cancel() 才能及时 stop timer，否则导致 goroutine 和内存泄漏。
context.WithTimeout 会自动触发 cancel 函数吗
会，但仅当超时时间到达时自动调用内部生成的 cancel 函数；它不会因为父 context 取消而“额外”触发——那是父 context 的责任。关键点在于：WithTimeout 返回的 cancel 是一个“一次性函数”，手动调用它或等超时触发，都会关闭返回的 ctx.Done() channel，且后续再调用无效果。
常见错误是：启动 goroutine 后忘记 defer 调用 cancel，导致 timer 持续运行、goroutine 泄漏。即使业务逻辑提前完成，不调用 cancel，timer 仍会走到超时才释放资源。
- 必须显式调用
cancel()（通常 defer），否则 timer 不会被 stop - 超时触发的 cancel 和手动调用 cancel 效果完全一致：关闭
ctx.Done()、停止内部 timer、释放关联的 goroutine - 重复调用
cancel()安全，但无意义
为什么 ctx.Err() 在超时后才变成 context.DeadlineExceeded
context.DeadlineExceeded 是一个预定义的 error 变量，它只在 timer 触发、内部 cancel 执行后才被写入 context 的 err 字段。在此之前，ctx.Err() 返回 nil；超时发生瞬间，err 被设为 context.DeadlineExceeded，之后所有调用都返回该值。
注意：这个 error 不可修改，也不包含时间戳或堆栈——如果需要诊断超时发生点，得靠日志或 trace 上下文补充。
-
ctx.Err()不是实时计算的，而是读取 context 内部原子存储的 err 值 - 一旦变为
context.DeadlineExceeded，就不会再变回nil，哪怕你又调用了cancel() - 不要用
==直接比较 error 文字，应使用errors.Is(err, context.DeadlineExceeded)
WithTimeout 嵌套时的取消优先级和 timer 行为
嵌套 WithTimeout（比如 WithTimeout(WithTimeout(parent, t1), t2)）会导致多个 timer 并存，但取消行为由“最先触发者”决定：哪个 timer 先到时间，就先触发其 cancel，进而关闭整个链路的 Done() channel。父 context 取消也会立即传播，无需等待子 timer。
问题在于：未被触发的 timer 不会自动 stop，可能继续持有资源。例如外层 5s、内层 10s，5s 到时外层 cancel，但内层 timer 还在跑，直到 10s 才自己 stop——这属于冗余开销。
- 嵌套 timeout 不提升可靠性，反而增加 timer 管理负担
- Go 官方建议避免嵌套 WithTimeout/WithCancel，优先用单层 + 显式 cancel 控制
- 若需多条件取消（如“5s 或收到信号”），应使用
context.WithCancel配合 select，而非套 timeout
测试中 mock 或控制 WithTimeout 的超时触发时机
无法直接 mock WithTimeout，因为它依赖系统时钟。可靠做法是把 timeout 逻辑抽离为可注入参数，测试时传入极短时间（如 1 * time.Millisecond）并配合 time.Sleep 触发；更健壮的方式是使用 clock 类库（如 github.com/benbjohnson/clock）替换 time 包行为。
另一个常见坑：测试里用 time.Now().Add(1 * time.Second) 构造 deadline 手动调 WithDeadline，但这绕过了 WithTimeout 的 timer 启动逻辑，容易掩盖 timer 未 stop 的 bug。
- 单元测试中避免依赖真实时间，优先用可控的 deadline 或 clock 接口
- 集成测试可接受短超时 + Sleep，但要确保 goroutine 已退出（如用 sync.WaitGroup 或检查 channel 关闭）
- 切勿在测试中写
time.Sleep(2 * time.Second)等待 timeout——这会让测试变慢且不稳定
真正容易被忽略的是：WithTimeout 创建的 timer 在 cancel 后是否真的被 GC 回收。答案是——只有调用 cancel() 才 stop timer 并解除引用；否则 timer 持有 context 引用，context 又可能持有 handler、buffer、甚至 http.Request，形成隐式内存泄漏。这个链路往往在压测时才暴露。
