必须用context.WithXXX而非context.Background()，因为后者是空根上下文，无取消、超时或值存储能力；直接使用将丧失context核心价值——传播取消信号与请求级数据，导致下游无法感知超时、取消或读取requestID等关键信息。
为什么必须用 context.WithXXX 而不是直接传入原始 context.Background()
因为 context.Background() 是一个空的根上下文，没有任何取消信号、超时或值存储能力。如果所有函数都直接用它，就彻底失去了 context 的核心价值——传播取消和携带请求作用域数据。实际调用链中，下游函数无法感知上游是否已超时或被取消，也无法读取上游注入的 requestID 或 userID 等关键信息。
正确做法是：上游创建带属性或带生命周期控制的子 context，再一路向下传递。例如 HTTP handler 中从 req.Context() 派生，而不是重造一个 context.Background()。
如何安全地在函数间传递并扩展 context 值
Go 的 context.Value 是类型不安全的，容易因 key 类型冲突或类型断言失败导致 panic。别用字符串或 int 作 key。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义私有未导出的 struct 类型作为 key，比如
type ctxKeyRequestID struct{} - 用
context.WithValue(parent, ctxKeyRequestID{}, "abc123")注入值 - 下游用相同 key 类型做断言：
if id, ok := ctx.Value(ctxKeyRequestID{}).(string); ok { ... } - 避免嵌套多层 value 注入——优先用结构体字段或中间件统一注入，而非层层 WithValue
cancel 函数该在哪儿调用？常见泄漏点
context.WithCancel、WithTimeout、WithDeadline 返回的 cancel 函数，必须且仅由创建它的那一层调用。若在被调函数里调用，会导致上游提前终止；若完全不调用，会泄漏 goroutine 和 timer。
- HTTP handler 中，应在 defer 里调用 cancel（但注意：不能 defer 在 middleware 外层，否则可能早于 handler 返回）
- 启动子 goroutine 时，应把带 cancel 的 context 传入，并确保 goroutine 退出时 cancel 被触发（或由父 context 自动触发）
- 数据库查询等阻塞操作后，不要“忘记” cancel —— 即使操作已完成，也建议显式调用，避免残留 timer
goroutine 场景下 context 传递的典型错误模式
并发函数中直接用闭包捕获外部 context 变量，看似能用，实则危险：若该变量后续被重新赋值（如循环中反复 ctx = context.WithTimeout(...)），goroutine 实际拿到的可能是过期或错误的 context。
- 务必显式将 context 作为参数传入 goroutine 函数，例如
go worker(ctx, job)，而非go func() { worker(ctx, job) }() - 不要在 select 中只监听
ctx.Done()就 return，还要检查ctx.Err()是否为context.Canceled或context.DeadlineExceeded，以便区分正常结束与异常中断 - 使用
context.WithTimeout时，timeout 值应基于该函数自身预期耗时，而非继承上游剩余时间——需用context.WithTimeout(ctx, time.Second*5)，而不是硬写死time.Second*5忽略父 context 限制
真正难的不是传 context，而是判断该不该取消、何时取消、取消后资源是否清理干净。比如一个函数启动了多个子 goroutine 并共享同一个 context，其中一个子 goroutine 提前返回并调用了 cancel，其余 goroutine 就会立刻收到 Done 信号——这未必符合业务语义。这类耦合需要靠明确的协作协议，而不是依赖 context 自动传播。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
