context.Context 生命周期由开发者代码决定，框架仅传递请求专属 ctx，其超时、取消均绑定单次 HTTP 请求，goroutine 必须在启动前检查 ctx.Err() 并显式传入派生 ctx。
context.Context 的生命周期不是由框架决定的，而是由你创建和传递它的代码决定的。Go 没有“框架内置 Context 管理”这回事——所有 context.Context 都来自标准库 context 包，框架（如 Gin、Echo、net/http）只负责在合适时机创建并传入，剩下的全靠你自己维护。
为什么 HTTP handler 里的 ctx 一结束就失效
HTTP server（比如 net/http 或 Gin）会在每次请求到来时调用 handler.ServeHTTP，并把该请求专属的 context.Context 作为参数传入（Gin 是 c.Request.Context()，net/http 是 r.Context()）。这个 ctx 的生命周期严格绑定到本次 HTTP 连接：客户端断开、超时触发、响应写出完成，它就会被取消。
- 它不是全局的，也不是复用的，每个请求一个独立实例
- 框架不会帮你“延长”它的生命——一旦 handler 函数返回，
ctx.Done()很可能已关闭，再监听也没意义 - 如果你在 handler 里启了 goroutine 却没显式传入
ctx，那个 goroutine 就脱离了请求生命周期控制，容易变成 goroutine 泄漏
context.WithCancel 和 context.WithTimeout 的派生必须在 request scope 内完成
你不能在包级变量或 init 函数里提前创建带取消/超时的 ctx 并试图复用。所有派生操作都得发生在 handler 入口或其调用链中，否则：
-
context.WithCancel(context.Background())创建的子 ctx 没有父级关联，cancel() 后无法影响上游 - 用
context.WithTimeout但父 ctx 是context.Background()，那超时只是孤立信号，和请求无关 - 若在中间件里派生却没把新
ctx注入*http.Request（如用r.WithContext(newCtx)），下游 handler 拿到的仍是原始 ctx，你的超时设置等于没生效
goroutine 中监听 ctx.Done() 的常见失效场景
最典型的错误是：在 goroutine 启动后才去读 ctx.Done()，但此时 ctx 可能早已被 cancel —— 因为 handler 已返回，HTTP 连接已关闭。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 务必在 goroutine 启动前就检查
ctx.Err() != nil，避免无意义启动 - 监听时用
select { case 做非阻塞判断，而不是直接 <code> - 如果 goroutine 要执行长任务（如写文件、发消息），必须在循环内部反复检查
ctx.Err()，不能只在开头 check 一次 - 不要把
ctx存进 struct 字段长期持有——它会过期，且结构体可能被多个请求复用（比如 Gin 的gin.Context实例池）
context.WithValue 的键必须是自定义类型，且不能用于跨请求传递
很多人用 context.WithValue(ctx, "user_id", 123)，但字符串键会导致冲突和类型不安全；更严重的是，误以为 WithValue 能让值“活过请求生命周期”。
立即学习“go语言免费学习笔记（深入）”；
- 键必须是 unexported 类型，例如
type userIDKey struct{}，避免第三方包意外覆盖 -
WithValue附加的值随ctx一起销毁，绝不能当成缓存或状态存储 - 不要用
WithValue传函数参数（如数据库连接、logger 实例）——这些应该通过依赖注入传入，而非塞进 context - 框架（如 Gin）提供的
c.Set()/c.MustGet()是对WithValue的封装，本质一样，别滥用
ctx, cancel := context.WithTimeout(...)，而是确保从 HTTP 入口开始，每个 goroutine、每层调用、每个 I/O 操作都真正尊重这个 ctx 的 Done 通道——它不会自动传播，也不会自我续命，全靠你在每一处手动检查、传递和响应。 
