context.Background()仅用于程序绝对起点（如main函数、独立后台goroutine），context.TODO()是待办占位符，必须替换；二者底层相同但语义不同，误用将破坏超时控制与链路追踪。
context.Background() 该在哪些地方硬编码使用
它只适合出现在程序真正「无父上下文」的起点位置，不是所有空 context 都该用它。
常见误用是：在 HTTP handler 里直接调用 context.Background() 启动 goroutine——这会让子任务脱离请求生命周期，请求 cancel 时它还在跑。
-
main()函数入口，作为整个应用的根上下文起点 - 独立后台 goroutine（如健康检查、定时清理），且明确不隶属任何用户请求
- 单元测试中需要传入合法
context.Context，又不想引入取消逻辑干扰断言
context.TODO() 是个带 lint 警告的占位符
它不是“另一个空 context 选项”，而是代码里的待办标记。staticcheck 等 linter 会把它当问题报出来，上线前必须替换。
典型场景是函数签名已加了 ctx context.Context 参数，但调用方还没理清上下文来源，或你写工具函数时无法预判调用链路。
- 新写的公共函数，暂时不知道调用方会传什么 context，先填
context.TODO()占位 - 重构中某处 context 传播被切断，临时补一个，同时加 TODO 注释说明需修复路径
- 团队协作时，用它显式暴露「此处上下文归属未确认」，避免后续人盲目继承错误假设
两者底层完全一样，但语义错位会破坏可观测性
context.Background() 和 context.TODO() 返回的都是 emptyCtx，不可取消、无 deadline、不存值——运行时零差异。
真正出问题的不是它们本身，而是你本该从某个带 traceID / timeout / auth 的父 context 派生，却退化到空 context。
- HTTP handler 内部用
context.Background()，日志里就丢掉了 request ID 关联 - 生产代码里留着
context.TODO()，等于主动放弃超时控制和链路追踪能力 - 用
context.TODO()替代context.Background()在main()里，会让 code review 人怀疑你是不是根本没理解上下文树结构
怎么一眼判断该用哪个
问自己两个问题：
1. 这个 context 是不是整棵树的绝对起点？如果是，且确定它永远不该被 cancel 或带值，选 context.Background()。
2. 这个 context 是不是“我现在还不知道该从哪来”，且已有计划后续补全？那就必须用 context.TODO()，并确保 CI 流程能拦截它漏网。
没有中间态。写完发现用了 context.TODO() 却没再改，说明上下文传播链已经断了——这不是风格问题，是可观测性和稳定性隐患。
