必须显式传递 context.context 并在所有阻塞及耗时操作中检查 ctx.done()，否则超时控制失效；纯 cpu 计算需手动轮询，不可仅依赖外部 ctx 或 time.sleep 模拟超时。
goroutine 启动时必须用 context.WithTimeout 包裹
直接启动 goroutine 而不传入带超时的 ctx，等于放弃控制权。哪怕你在外层调用了 context.WithTimeout，如果没把返回的 ctx 显式传进去，goroutine 就不会响应超时信号。
常见错误写法：
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) defer cancel() go someTask() // ❌ 没传 ctx，超时完全无效
正确做法是让任务函数接收 ctx context.Context 作为第一个参数，并在启动时传入：
go someTask(ctx) // ✅ 可被取消
- 所有可能阻塞的操作（
http.Do、db.QueryContext、time.Sleep、ch 等）都必须配合 <code>ctx使用 - 不要依赖 goroutine 内部的
time.After或time.Sleep来模拟超时——它和外部ctx无关，无法联动取消 - 如果任务本身是纯 CPU 计算（无阻塞调用），需手动轮询
ctx.Done()，否则不会退出
goroutine 内部必须检查 ctx.Done()，不能只靠一次调用
很多开发者以为只要把 ctx 传给 http.Client.Do 或 db.QueryContext 就万事大吉，但实际任务链常包含多个步骤：比如先查 DB，再调第三方 API，最后做 JSON 解析。如果中间某步耗时过长（如解析大文件），而它不感知 ctx，整个 goroutine 就卡死。
示例中容易忽略的“非阻塞但耗时”环节：
func someTask(ctx context.Context) error {
// 步骤1：DB 查询（支持 ctx）
rows, err := db.QueryContext(ctx, "SELECT ...")
if err != nil {
return err
}
defer rows.Close()
// 步骤2：遍历并解析大量数据（纯 CPU，不阻塞，但可能很慢）
for rows.Next() {
var data string
if err := rows.Scan(&data); err != nil {
return err
}
// ❌ 这里没检查 ctx，即使超时了也会继续跑完全部数据
process(data) // 耗时操作
}
return nil
}
- 在循环体内部插入
select检查：case - 避免在
for循环中做无条件长耗时计算，尤其当输入规模不可控时 - 对 CPU 密集型逻辑，可按批次处理，并在每批次后检查
ctx.Err()
cancel 函数必须调用，否则 timerCtx 泄漏
context.WithTimeout 返回的 cancel 函数不只是“取消用”，它还负责清理底层的 timer 和关闭 done channel。漏调会导致 goroutine 和定时器持续驻留，形成资源泄漏。
典型反模式：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) // 忘记 defer cancel()，或只在成功路径调用，失败路径遗漏
- 一律用
defer cancel()，放在ctx创建之后立刻写，别犹豫 - 如果
ctx被传给多个 goroutine，cancel()仍只需调用一次——它会广播给所有监听者 - 注意：
cancel()是幂等的，重复调用无副作用，但提前调用会让后续使用该ctx的操作立即失败
超时时间必须从任务入口统一计时
不要在每个子步骤分别设超时（比如 DB 设 3 秒、HTTP 设 2 秒），这样总耗时不可控，且无法反映真实请求生命周期。超时应从 goroutine 启动那一刻开始倒计时，覆盖整个任务链。
错误示范：
go func() {
ctx1, _ := context.WithTimeout(context.Background(), 3*time.Second)
db.QueryContext(ctx1, ...) // ✅ DB 有超时
ctx2, _ := context.WithTimeout(context.Background(), 2*time.Second)
http.Do(req.WithContext(ctx2)) // ✅ HTTP 有超时
}()
问题在于两个 ctx 互不关联，总耗时可能是 5 秒以上，且无法统一中断。
- 只创建一个
ctx，从入口传到底层所有调用点 - 若下游服务本身也用了
context（如标准库net/http、database/sql），确保它们接收的是你传入的同一个ctx，而不是新造的 - 对第三方 SDK，确认其是否支持
Context参数；不支持的需封装或换库，不能妥协
context.WithTimeout，而是确保它像氧气一样渗透到每一层调用——从 handler 到 service 到 DAO，再到驱动底层。任何一处断点，都会让超时变成摆设。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
