context.withtimeout没生效的根本原因是新context未透传至底层i/o操作或未监听ctx.done()。go context仅提供取消信号，不自动中断goroutine或连接，需手动配合withcontext、querycontext及select监听。
context.WithTimeout 为什么没生效？
根本原因通常是 context.WithTimeout 返回的新 context 没有传给真正执行 I/O 的函数，或者下游代码压根没检查 ctx.Done()。Go 的 context 不会自动中断 goroutine 或关闭连接，它只提供信号通道。
常见错误现象：http.Client 发起请求后，即使 context 已超时，goroutine 仍在阻塞等待响应；数据库查询不响应 cancel；自定义函数里漏掉 select 判断 ctx.Done()。
- 必须把 context 一路透传到最底层可取消操作（如
http.NewRequestWithContext、db.QueryContext） - 自己写的阻塞逻辑（比如轮询、sleep）要主动监听
ctx.Done()，不能只靠上层传入 - 注意
time.AfterFunc或time.Sleep不受 context 控制，得换成time.After+select
http.Client 要不要自己包一层 WithContext？
不用。标准库的 http.Client 本身不带 context，但它的 Do 方法接受 *http.Request，而 http.Request 支持绑定 context —— 正确做法是用 req.WithContext(ctx)，而不是封装 client。
使用场景：微服务间 HTTP 调用需统一超时、支持链路取消；中间件中注入 trace ID 和 deadline。
立即学习“go语言免费学习笔记（深入）”；
- 别写
client.DoWithContext(ctx, req)这种不存在的方法 - 正确姿势：
req := http.NewRequest("GET", url, nil); req = req.WithContext(ctx) - 如果用了
http.DefaultClient，记得它没有默认 timeout，必须靠 request 级 context 控制，否则底层 TCP 连接可能卡住几分钟
cancel() 函数调用时机不对会怎样？
过早调用 cancel() 会导致 context 立即关闭，哪怕还没开始干活；过晚或漏调，则资源泄漏、goroutine 泄露、超时失效。
典型坑：defer cancel() 放在函数开头，结果函数中途 panic，cancel 没执行；或者在 goroutine 里启动子任务后，主函数立刻调了 cancel()，子任务还没来得及拿到 context 就被终止。
-
cancel()应该和 context 使用范围严格匹配：谁创建，谁负责调用（通常在函数 return 前） - 启动新 goroutine 时，如果它需要独立生命周期，应该用
context.WithCancel(parent)并在 goroutine 内部控制 cancel，而不是复用外部 cancel - HTTP handler 中，
cancel()一般由 net/http 自动触发（请求结束/断开），你只需确保 handler 内部逻辑响应ctx.Done()
context.Value 适合存什么？
只适合传**请求级只读元数据**，比如 trace ID、user ID、request ID。不适合传配置、工具实例、数据库连接等——它们该通过参数或依赖注入传递。
性能影响：每次 ctx.Value() 是 O(n) 链表遍历，嵌套深了有开销；更严重的是语义污染——函数行为变得隐式依赖 context，难以测试和复用。
- 避免存 struct 指针或 map，容易引发并发写 panic
- 键类型推荐用未导出的私有类型（如
type ctxKey string），防止和其他包 key 冲突 - 如果发现多个地方都在取同一个
ctx.Value("user")，说明该抽象成显式参数或中间件装饰器
