Golang Context包控制链路生命周期_超时取消与元数据传递-Golang-PHP中文网

context.WithTimeout没生效是因为它只关闭Done通道，需手动监听ctx.Err()或select ctx.Done()并主动退出；HTTP客户端、数据库查询等必须配合ctx使用，goroutine也需传入并监听ctx。

golang context包控制链路生命周期_超时取消与元数据传递

context.WithTimeout 为什么没生效？

Go 的 context.WithTimeout 不会自动中断正在运行的函数，它只负责在超时后关闭返回的 ctx.Done() channel。你得自己监听这个信号，并主动退出逻辑。

常见错误是写了 ctx, cancel := context.WithTimeout(parent, time.Second)，却没在后续操作中检查 ctx.Err() 或 select ctx.Done()。

必须在可能阻塞或耗时的操作前、中、后主动判断 ctx.Err() != nil
HTTP client、database query、channel receive 等都应配合 ctx 使用（如 http.Client 的 Do 方法支持传入 ctx）
手动启动的 goroutine 如果没传 ctx 或没监听 Done()，超时后照样继续跑

示例：

context.WithValue

key 类型建议用私有 unexported 类型，比如 type userIDKey struct{}，再定义全局变量 var userIDKeyKey userIDKey
不要用 int、string 这类基础类型当 key，除非你能确保全程用同一个变量
context.Value 只适合传传递请求范围的元数据（如 traceID、userID），别传业务对象或大结构体

cancel 函数忘记调用会导致什么？

context.WithCancel、WithTimeout、WithDeadline 返回的 cancel 函数必须被调用，否则底层 timer 或 goroutine 无法释放，造成内存泄漏和 goroutine 泄漏。

现象包括：

pprof/goroutine 中持续看到大量 runtime.gopark 卡在 timerProc 或 selectgo
runtime.ReadMemStats 显示 Mallocs 持续上涨，但 Free 不跟上
长时间运行的服务 RSS 内存缓慢爬升

Golang Uber Dig
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载
所有 cancel() 应该放在 defer 中，除非你明确知道取消时机并能保证执行
如果是 HTTP handler，cancel 应在 handler 返回前调用，不要依赖中间件自动处理（除非你确认中间件可靠）
用 context.TODO() 或 context.Background() 启动的链路，如果中途加了 WithCancel，更要盯紧 cancel 调用点

HTTP server 中 context 超时为何不终止连接？

Go 的 http.Server 默认不读取 handler 里 ctx.Done()，它只控制 handler 函数的执行时间（通过 HandlerTimeout 或 ReadTimeout 等字段），但不会主动 kill underlying connection。

也就是说：你用 ctx, _ := context.WithTimeout(r.Context(), time.Second)，然后在 handler 里 sleep 3 秒，HTTP 连接仍保持打开，直到你的 handler 自己 return，或者 http.Server 的 WriteTimeout 触发。