context.WithTimeout没生效是因为未主动检查ctx.Done()或未将ctx传入底层可取消操作；cancel函数需及时调用以防资源泄漏；WithValue仅适用于请求级元数据；context不可长期持有于struct中。
context.WithTimeout 为什么没生效？
常见现象是调用了
，但 goroutine 依然没被取消，或者超时后函数还在跑。根本原因不是 context 本身“失效”，而是你没在关键路径上主动检查
或没把
传到底层可取消的操作里。
HTTP client、
、
等标准库组件支持 context，但必须显式传入（比如
、
）
自己写的循环或阻塞操作（如 for-select、time.Sleep）必须手动监听
，否则 context 完全不起作用
别用
模拟超时逻辑来替代
——它和 context 的取消机制不联动
cancel 函数该谁调用？漏调会怎样？
和
返回的
函数，本质是释放底层 timer 和 channel 资源。不调用它不会导致 context 立即“泄漏”，但会拖慢 GC、累积 goroutine（尤其在高频创建 context 的场景下）。
如果 context 是短期任务（比如一次 HTTP handler），应在 handler 结束前调用
，哪怕已超时
如果 context 是长生命周期（比如服务启动时创建的 root context），通常不手动 cancel，靠进程退出自然清理
注意：多个 goroutine 同时调用同一个
是安全的，但重复调用无意义，且可能掩盖本该只调一次的逻辑错误
value 类型传参为什么建议只传 request-scoped 数据？
不是通用的参数传递工具，它的设计目标是透传跨多层调用的、与请求生命周期一致的元数据（如 traceID、user ID、locale）。滥用会导致代码难以测试、调试和维护。
不要用
传业务逻辑所需的结构体或接口实现——改用函数参数或依赖注入
key 类型强烈建议用私有 unexported 类型（如
），避免不同包之间 key 冲突
值对象最好是不可变的；若传指针，需确保其生命周期不超过 context 本身，否则可能引发 panic 或读到脏数据
为什么不能把 context 存进 struct 做长期持有？
context 是“一次性”且“短命”的：它绑定明确的取消信号和 deadline。存成 struct 字段后，容易误以为能复用，结果导致超时时间错乱、取消信号丢失、甚至内存泄漏。
立即学习
“
go语言免费学习笔记（深入）
”；
典型反例：
+ 在构造时传入
—— 这让整个 service 失去上下文感知能力
正确做法：把
当作每个方法的第一个参数（如
），由调用方控制生命周期
如果真需要“默认 context”，应提供带 ctx 参数的构造函数，而不是在 struct 里固化一个
context 的核心约束就一条：它是单向流动、不可重置、不可持久化的信号载体。越想把它当“配置”或“状态容器”用，越容易掉进超时失效、cancel 遗漏、key 冲突这些坑里。
context.WithTimeoutctx.Done()ctxdatabase/sqlnet.Connhttp.NewRequestWithContextdb.QueryContextctx.Done()time.AfterFunccontext.WithTimeoutcontext.WithCancelWithTimeoutcancelcancel()cancel()context.WithValuecontext.WithValuetype ctxKey stringtype Service struct { ctx context.Context }context.Background()ctxfunc (s *Service) Do(ctx context.Context, req Req)