context.background()仅限main函数、独立goroutine和单元测试中使用；http handler必须用r.context()派生子上下文，否则导致超时与取消失效；context.todo()是待修复占位符，需配todo注释说明来源；传播链断裂才是根本问题。
context.Background() 不能出现在 HTTP handler 内部
重构时最容易踩的坑，是把 context.Background() 直接塞进 http.HandlerFunc 或中间件里启动子任务。比如：
func handler(w http.ResponseWriter, r *http.Request) {
go doAsyncWork(context.Background()) // ❌ 错误：脱离请求生命周期
}
这会导致子 goroutine 完全无视客户端断连、超时或主动 cancel——哪怕用户已关闭页面，它还在跑。真正该用的是 r.Context() 派生：
ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)- 下游调用（DB 查询、RPC、HTTP client）必须传这个
ctx，不能 fallback 到Background() - 如果 handler 本身不处理取消，至少要确保所有子任务继承父上下文，否则链路追踪和超时控制全失效
context.TODO() 是 lint 警告触发器，不是兜底选项
重构中遇到函数签名已加 ctx context.Context 参数，但调用链还没理清时，context.TODO() 是唯一合法占位符——但它不是“暂时能用”，而是“必须立刻修复”的信号。
常见误用场景：
- 在公共工具函数里写
func DoSomething(ctx context.Context) { ... }，却直接填context.TODO()而不标注后续补全路径 - CI 流程没接入
staticcheck，导致TODO()漏网上线，等于主动放弃可观测性 - 团队协作时看到
TODO()却没配对注释说明“此处应从 auth middleware 注入 ctx”，后续人只能猜
正确做法：每处 context.TODO() 必须紧挨着 TODO 注释，明确写出上下文来源，例如：// TODO: 从 authMiddleware 中提取 userCtx，替换为 req.Context()
main() 和独立 goroutine 是 Background 的唯一安全区
重构时若新增后台任务（如定时清理缓存、健康检查上报），只有以下位置可硬编码 context.Background()：
-
main()函数开头，作为整个应用上下文树的根节点 - 显式启动且与任何请求无关的 goroutine，例如：
go func() { ticker := time.NewTicker(30s); for range ticker.C { checkHealth(context.Background()) } }() - 单元测试中需要非 nil
context.Context又不想干扰逻辑，例如：testFunc(context.Background(), "input")
注意：即使在这里用 Background()，也建议尽快派生带 traceID 的子 context，比如 context.WithValue(context.Background(), "trace_id", uuid.New())，避免日志完全丢失上下文。
emptyCtx 本身没毛病，断裂的传播链才致命
context.Background() 和 context.TODO() 返回的都是 emptyCtx，运行时零差异——它们不带 deadline、不可取消、不存值。问题从来不在这两个函数本身，而在于你本该从一个有意义的父 context 派生，却退化到了空 context。
重构中真正要盯住的，是上下文传播是否连续：
- 检查每个接受
ctx context.Context的函数，是否把ctx传给了它调用的所有下游函数 - 特别留意中间件、装饰器、封装层——这些地方最容易漏传
ctx - 用
ctx.Value()传递数据时，确保 key 是 unexported 类型，避免跨包污染
重构完跑一遍 staticcheck -checks=SA1012，它会揪出所有未替换的 TODO() 和可疑的 Background() 误用。这点不难，但多数人忽略——等线上出问题再查，代价就大了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
