context.WithTimeout没生效是因为它只关闭Done通道，需手动监听ctx.Err()或select ctx.Done()并主动退出；HTTP客户端、数据库查询等必须配合ctx使用，goroutine也需传入并监听ctx。
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()，超时后照样继续跑
示例：
ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
defer cancel()
select {
case <-time.After(200 * time.Millisecond):
fmt.Println("slow op done")
case <-ctx.Done():
fmt.Println("timeout:", ctx.Err()) // 输出 "timeout: context deadline exceeded"
}valueFromContext 为什么取不到值？
context.WithValue 存的 key 必须是同一个变量地址，用字符串字面量或不同 struct 实例作 key 都取不到——因为 Go 的 == 比较的是底层指针或值，而 map 查 key 是用 == 判断相等性的。
立即学习“go语言免费学习笔记（深入）”；
典型坑：定义 key 时用了 "user_id" 字符串字面量存，又用另一个 "user_id" 字面量去取，看似一样，但编译器可能生成不同地址（尤其跨包时）。
- 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或selectgoruntime.ReadMemStats显示Mallocs持续上涨，但Free不跟上长时间运行的服务 RSS 内存缓慢爬升
所有
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 触发。
- 若想真正断开连接，需设置
http.Server的ReadTimeout/WriteTimeout/IdleTimeout - 更推荐做法是：handler 内部尽早响应，配合
select监听ctx.Done()并快速 write error response - 注意
net/http的ResponseWriter不是线程安全的，不能在多个 goroutine 里并发写
context 生命周期管理最麻烦的地方不在 API 多难记，而在“谁负责 cancel”“谁监听 Done”“key 怎么定义才不会散落各处”这三件事上——它们分散在不同包、不同协程、不同抽象层里，稍不注意就漏掉一环。
