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