context 用于控制 goroutine 生命周期和传递取消信号；必须传入 context.Context 的场景包括调用显式接受该参数的函数（如 QueryContext）、HTTP handler 中发起下游请求、启动需受控的子 goroutine 等。
context 不是用来传业务数据的，它是用来控制 goroutine 生命周期和传递取消信号的。
什么时候必须用 context.Context？
当你调用的函数或方法明确接受 ctx context.Context 参数时，就必须传——比如 http.NewRequestWithContext、database/sql.Conn.QueryContext、net/http.Server.Serve 的 handler 签名里带 context.Context。这些底层实现依赖 ctx.Done() 通道来响应取消或超时。
- HTTP handler 中需要主动发起下游请求（如调用另一个 API）时，应把入参
req.Context()传下去，否则上游中断（如客户端断开）无法传播到底层 - 启动子 goroutine 做异步工作且需受主流程控制时，必须传
context.WithCancel或context.WithTimeout派生的 ctx，否则 goroutine 可能泄漏 - 数据库查询、文件读写、RPC 调用等阻塞操作，若支持
Context版本，优先用xxxContext方法，避免死等
context.WithCancel 和 context.WithTimeout 怎么选？
两者都返回 (context.Context, context.CancelFunc)，区别在于触发取消的条件：WithCancel 需手动调用 cancel 函数；WithTimeout 在时间到达后自动调用 cancel。
- 用
WithCancel：当逻辑上存在“主动退出”条件，比如收到某个信号、某个 channel 关闭、状态机进入终态 - 用
WithTimeout：绝大多数网络 I/O 场景，例如 “最多等 5 秒”，它本质是WithDeadline(time.Now().Add(5 * time.Second)) - 别用
WithTimeout(0)或极小值（如1ns），这会导致上下文几乎立即取消，容易引发非预期失败 - cancel 函数必须调用，且建议用
defer cancel()，但要注意：如果父 context 已取消，再调用子 cancel 不会 panic，但也没效果
为什么不能把值塞进 context.WithValue 当全局变量用？
context.WithValue 是为传递请求范围的、不可变的元数据设计的（如用户 ID、trace ID、认证 token），不是为替代参数或配置项。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 值类型必须是可比较的，且建议用自定义 key 类型（如
type ctxKey string），避免字符串 key 冲突 - 不要传指针、函数、接口或大结构体——context 可能在多个 goroutine 间传递，值拷贝成本和并发安全风险会上升
- 下游必须用
value, ok := ctx.Value(myKey).(MyType)判断是否存在，不能假设一定有值；一旦漏判，可能 panic 或逻辑错乱 - 常见误用：把 logger、DB 连接、配置对象塞进去——这些该通过函数参数或依赖注入传，而不是藏在 context 里
goroutine 泄漏最常踩的坑是什么？
最典型的是：派生了子 context，启了 goroutine，但没在合适时机调用 cancel，或 cancel 被 defer 在错误的作用域里。
- 在 for-select 循环中监听
ctx.Done()时，忘记 break 或 return，导致循环继续执行，goroutine 无法退出 - 用
go func() { ... }()启动匿名 goroutine，但没把 ctx 作为参数传进去，导致它完全不受控制 - 在 HTTP handler 里用
context.WithTimeout(r.Context(), ...)，但 handler 返回后没调用 cancel——其实这时父 context（r.Context()）已结束，子 cancel 是空操作；真正该 cancel 的是自己新启的子 goroutine 所用的子 context - 把 cancel 函数传给其他包或模块，又没文档说明“调用者负责 cancel”，结果谁都不调
context 的 cancel 传播是单向的（父→子），且不可逆；一旦被 cancel，所有子 context 的 Done() 都会关闭，但反过来不行。这个模型简单，但也意味着你得清楚每一层是谁派生的、谁该负责终止。
