context传递失败的本质是“传了但未被使用”或“使用中断链”，典型表现为context deadline exceeded错误频发且下游不受上游超时控制。
Context传递失败不是“没传”，而是“传了但没被用”或“用了但断了链”——最常见后果是context deadline exceeded错误反复出现，且调用链下游完全不受上游超时控制。
为什么context.Background()是最大隐患
很多开发者以为“只要参数里写了ctx context.Context就算传了”，但实际在子goroutine里直接调用context.Background()，等于主动撕掉任务手册、另起一本空白册子。上游设的5秒超时、用户手动取消信号，到这里全部失效。
常见错误模式：
- 在
go func() { ... }()里重新调用context.Background()，而不是接收并使用入参ctx - 中间件或工具函数内部硬编码
http.Client{Timeout: 30 * time.Second}，绕过传入的ctx - 数据库驱动（如
pgx）调用QueryRow(ctx, ...)时传了ctx，但后续Scan()没做超时感知，导致body读取阶段卡死
HTTP客户端中context.WithTimeout必须和defer cancel()配对使用
单独调用context.WithTimeout(parent, 5*time.Second)只是创建新上下文，不调用cancel()会导致底层定时器泄漏，尤其在高频请求场景下会缓慢拖垮服务。
正确写法要点：
-
ctx, cancel := context.WithTimeout(r.Context(), 8*time.Second)—— 一定要基于r.Context()（net/http）或c.Request.Context()（Gin），不能用context.Background() -
defer cancel()必须紧跟在WithTimeout之后，不能放在if分支里，也不能漏写 - 如果后续还要派生子context（比如调用下游RPC），应基于这个
ctx再调用WithTimeout或WithValue，而非回到r.Context()
goroutine启动时忘记把ctx作为参数传进去
这是最隐蔽的传递失败：函数签名有ctx，调用方也传了，但启动goroutine时没把它塞进闭包里。
错误示例：
func handleRequest(ctx context.Context, data string) {
go func() { // ❌ 没接收ctx，闭包里只能访问外层变量，但外层ctx可能已结束
time.Sleep(10 * time.Second)
db.QueryRow(ctx, "SELECT ...") // 此处ctx可能已Done，但没人检查
}()
}
修复方式只有两种：
- 显式把
ctx作为参数传给匿名函数：go func(ctx context.Context) { ... }(ctx) - 改用具名函数，并确保其第一个参数是
ctx context.Context，调用时明确传入
注意：ctx.Err()必须在每个关键操作前检查，不能只在函数开头check一次就认为万事大吉——尤其是IO操作之间存在间隙时。
中间件或封装层偷偷替换了ctx
有些日志中间件、鉴权中间件或metric上报工具，会在处理过程中调用ctx = context.WithValue(ctx, key, value)，这本身没问题；但若它们内部又用context.Background()发起HTTP请求或DB查询，就等于在链路中间挖了个洞。
排查建议：
- 搜索代码中所有
context.Background()和context.TODO()，逐个确认是否真有必要 - 对第三方库（如
redis-go、ent）检查其方法是否接受ctx参数，避免因版本差异导致静默降级为无context调用 - 在关键路径加日志：
log.Printf("ctx deadline: %+v", ctx.Deadline())，验证是否真的继承了上游设置
真正难缠的不是“没传context”，而是“看起来传了，实则某一层悄悄截断或重置了它”。每次遇到context deadline exceeded，优先盯住调用栈最深那层是否还在用原始ctx，而不是默认它一定安全。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
