应优先使用 context.withtimeout 实现超时控制，它从当前时间起计时、自动取消，需成对使用 ctx 和 cancel 函数，避免 goroutine 泄漏或传给不支持 context 的旧接口。
用 context.WithTimeout 生成带超时的 Context 最直接
不是所有 timeout 场景都该用 WithTimeout，但绝大多数 HTTP 客户端调用、RPC 请求、数据库查询都需要它。它的行为明确：从当前时间起计时，到点自动 cancel，返回的 ctx 和 cancel 函数必须成对使用。
常见错误是漏掉 defer cancel()，导致 goroutine 泄漏；或把 ctx 传给不支持 context 的老接口（比如某些未升级的 redis/v8 客户端）。
-
context.WithTimeout(parentCtx, 5*time.Second)返回两个值：ctx（可传递的上下文）和cancel（必须调用的清理函数） - 超时后
ctx.Done()会关闭，ctx.Err()返回context.DeadlineExceeded - 若父 context 已 cancel 或 deadline 更早，子 context 会继承更严格的限制，不会“延长”超时
GoLand 里用 Alt+Enter 快速补全 WithTimeout 模板
在函数开头写 ctx :=，光标停在冒号后，按 Alt+Enter → 选 “Add context.WithTimeout call”，IDE 会自动插入完整行并导入 context 包。
注意它默认用 context.Background() 作 parent，实际项目中多数应换成传入的 req.Context() 或 ctx 参数，否则会断开请求链路。
- 如果 parent 是
nil，GoLand 不会报错，但运行时 panic：“context: cannot create child from nil context” - 时间参数建议用常量或配置项，避免硬编码数字，例如
defaultHTTPTimeout = 10 * time.Second - 补全后立刻检查是否多写了
cancel()—— GoLand 不会帮你加defer，这步必须手动补
别把 WithValue 和 WithTimeout 混在一个链里滥用
很多人习惯链式调用：context.WithTimeout(context.WithValue(...))，看起来简洁，但容易掩盖生命周期问题。value 的存活期由最外层 context 决定，而 timeout 可能提前结束，导致 value 还没被读就失效。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
真实 Web 服务中，推荐分层：外层用 WithTimeout 控制整体耗时，内层用 WithValue 注入请求 ID、用户信息等只读数据，且确保这些 key 类型是 unexported（如 type ctxKey int），避免冲突。
- 不要用字符串当
WithValue的 key，例如ctx = context.WithValue(ctx, "user_id", id)—— 极易和其他包冲突 - 超时 context 不该用来存业务数据；value context 不该承担取消职责
- GoLand 的 Quick Documentation（Ctrl+Q）悬停在
WithValue上时，会强调 “values are not propagated to background contexts”，这点常被忽略
测试超时逻辑时，别只靠 time.Sleep
本地跑测试验证 WithTimeout 是否生效，不能只写 time.Sleep(6 * time.Second) 看会不会 panic。真实环境里，goroutine 可能在 sleep 前就被调度走，或因 GC 暂停延迟触发 Done。
正确做法是用 select + ctx.Done() 显式等待，并检查 ctx.Err() 类型：
select {
case <p>GoLand 调试时，在 <code>ctx.Done()</code> 那行设断点，观察 channel 是否关闭、变量视图里 <code>ctx.err</code> 字段是否为 <code>deadlineExceededError{}</code>，比日志更可靠。</p>
