必须接收ctx context.Context的函数是可能阻塞、发起I/O或启动需受控goroutine的函数，如http.Client.Do、sql.DB.QueryContext；纯内存计算函数无需ctx，硬编码context.Background()会使调用方失去超时、取消等控制权。
不是所有函数都需要加 context.Context 参数，加错地方反而破坏可测试性和可维护性。
哪些函数必须接收 ctx context.Context？
只在函数可能阻塞、发起 I/O 或启动 goroutine 时才需要显式接收 ctx。比如：
-
http.Client.Do、sql.DB.QueryContext、grpc.ClientConn.Invoke这类会等待外部响应的调用 - 启动长期运行 goroutine 的函数，且该 goroutine 需响应取消（如轮询、监听）
- 封装了上述行为的业务函数，比如
fetchUserProfile(ctx, id)内部做了 HTTP 请求
纯内存计算、立即返回的逻辑（如 calculateHash(data)、parseJSON(b)）传 ctx 是冗余的，也违背“职责清晰”原则。
为什么不能在函数内部硬写 context.Background()？
硬编码 context.Background() 或 context.TODO() 会让调用方彻底失去控制权——超时、取消、元数据都不可注入。
立即学习“go语言免费学习笔记（深入）”；
常见错误写法：
func getData() (string, error) {
ctx := context.Background() // ❌ 调用方无法干预
return db.QueryRowContext(ctx, "SELECT ...").Scan(&v)
}
正确做法是让上层决定传什么 ctx，下层只负责传递和消费：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
func getData(ctx context.Context) (string, error) {
return db.QueryRowContext(ctx, "SELECT ...").Scan(&v) // ✅
}
HTTP handler 中尤其要注意：必须用 r.Context()，而不是新建 context.Background()。
context.WithTimeout 和 context.WithDeadline 怎么选？
选哪个取决于你控制的是“持续时间”还是“绝对时间点”：
- 用
context.WithTimeout：适合“最多等 5 秒”，比如下游服务调用、缓存查询 - 用
context.WithDeadline：适合“必须在 2026-06-13T08:30:00Z 前完成”，比如定时任务续期、分布式锁保活
关键细节：
- 两者都会自动关闭
Done()通道，但cancel()函数必须被调用，否则 timer 不释放、goroutine 泄露 -
defer cancel()是高频遗漏点，不是可选项 - 若
WithDeadline传入的时间早于当前时间，ctx.Err()立即返回context.DeadlineExceeded - 不要对同一个
ctx多次调用WithTimeout—— 子上下文 deadline 是叠加的，容易误判
context.WithValue 什么时候能用？
仅限传递轻量、请求级、不可变的元数据，比如 traceID、userID、locale。它不是参数传递的替代品。
安全用法要点：
- 键类型必须是自定义未导出类型：
type userKey string，避免字符串键冲突 - 取值时必须判断非空：
if uid, ok := ctx.Value(userKey("uid")).(int); ok { ... } - 严禁塞入结构体指针（如
*sql.DB、http.Client），这违反依赖注入原则，也阻碍单元测试
真正容易被忽略的是：一旦用了 WithValue，调试时你得靠日志或断点才能确认值是否被正确注入——它没有编译时检查，也没有 IDE 提示，全靠约定和纪律。
