Context超时后下游函数仍在执行，因context.WithTimeout仅设截止时间而不强制中断goroutine；下游需主动轮询ctx.Done()退出，常见错误是仅开头检查一次，正确做法是在阻塞点或循环体内持续判断。
Context超时后为什么下游函数还在执行？
因为 context.WithTimeout 只是给 ctx 设定一个截止时间，并不会自动中断正在运行的 goroutine。Go 没有强制取消机制，下游必须主动检查 ctx.Done() 并退出。
常见错误是只在函数开头检查一次 ctx.Err()，但后续长时间操作（如数据库查询、HTTP 调用、循环处理）没再轮询。正确做法是在关键阻塞点或循环体内反复判断：
for i := 0; i < n; i++ {
select {
case <-ctx.Done():
return ctx.Err() // 立即返回
default:
}
// 处理第 i 项
}
- HTTP 客户端需传入带 cancel 的
ctx：使用http.NewRequestWithContext(ctx, ...)，而非手动设置req.Cancel（已弃用） - 数据库查询（如
database/sql）要传ctx到QueryContext/ExecContext，否则超时无效 - 自定义阻塞操作（如
time.Sleep）必须替换为select+time.After或使用timer := time.NewTimer并监听ctx.Done()
Debug：如何确认 Context 是否被正确传递？
最直接的方式是打印 ctx 的值——但 context.Context 是接口，直接 fmt.Println(ctx) 只显示类型和地址，看不出内容。应检查其内部字段：
if deadline, ok := ctx.Deadline(); ok {
fmt.Printf("deadline: %v\n", deadline)
}
fmt.Printf("err: %v\n", ctx.Err())
- 如果
ctx.Err()返回context.Canceled或context.DeadlineExceeded，说明上下文已结束，但调用方可能还没响应 - 若始终为
<nil>，可能是上游没调用WithCancel/WithTimeout，或传递时用了context.Background()/context.TODO()硬编码 - 检查调用链每层是否都把
ctx当作第一个参数传入，且没被意外覆盖（例如误写成func f(x, y int)忘了ctx）
为什么 WithValue 传的数据在下游取不到？
根本原因是用了不同 key 类型——context.WithValue 的 key 必须是可比较的，且下游使用的 key 变量必须和上游 WithValue 时的 key 是**同一个变量**，或至少是相同底层类型的同一实例。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
典型踩坑：
// ❌ 错误：每次 new 一个 struct{}{}，key 地址不同
ctx = context.WithValue(ctx, struct{}{}, "val")
// ✅ 正确：定义全局变量或包级常量
var TraceIDKey = struct{}{}
ctx = context.WithValue(ctx, TraceIDKey, "abc123")
// 下游也用 TraceIDKey 取值
- 不要用
string做 key（虽然能用），容易拼错；推荐定义未导出的私有类型，如type ctxKey string，并用包级变量统一管理 -
ctx.Value(key)返回interface{}，务必做类型断言，且检查 ok：v, ok := ctx.Value(TraceIDKey).(string) - WithValue 仅用于传递请求范围的元数据（如 trace id、user id），绝不传业务逻辑对象或函数
调试时如何快速定位 Context 断点？
在怀疑断掉的位置加一行日志，输出 ctx 的状态和调用栈：
func handler(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
log.Printf("handler start: err=%v, deadline=%v, goroutine=%d",
ctx.Err(), ctx.Deadline(), runtime.NumGoroutine())
// …
}
- 配合
runtime.Stack打印当前 goroutine 栈（慎用，仅调试） - 用
ctx.Value查关键标识（如 trace id），确认是否从入口一路透传下来 - 如果某层函数接收了
ctx却没往下传（比如调了另一个不带 ctx 的 helper 函数），就是断点；此时应重构 helper 为接受ctx参数
真正麻烦的不是 Context 本身，而是人习惯性忽略它——只要有一处没传、没检查、没响应，整条链就失效。调试时别只盯错误信息，先看 ctx.Err() 在哪变成非 nil，再逆向查谁没监听它。
