context.context 不应用于传递业务参数，仅限传递取消信号、超时等控制信息；若必须传少量元数据，须用私有 key 类型和只读 value，并始终用“逗号 ok”安全断言。
Context 不能用来传业务参数
Go 的 context.Context 设计初衷是传递取消信号、超时控制和截止时间，**不是为传业务数据准备的**。官方文档明确警告：不要用 context.WithValue 存用户 ID、请求参数、配置等——这会让调用链变得隐晦、难以测试，且容易引发内存泄漏（值未被清理）或类型断言 panic。
如果真要传少量元数据，必须用 context.WithValue + 自定义 key 类型
某些场景绕不开（比如日志 traceID、认证 token），这时只能用 context.WithValue，但必须遵守两个硬约束：
- key 必须是**未导出的私有类型**（避免不同包冲突），不能用字符串或 int 直接当 key
- value 必须是**只读、可比较、无副作用**的类型（如
string、int、struct{}），禁止传指针或 map
示例：
// 正确：私有 key 类型
type ctxKey string
const userIDKey ctxKey = "user_id"
// 设置
ctx := context.WithValue(parentCtx, userIDKey, "u_12345")
// 获取（务必检查 ok）
if userID, ok := ctx.Value(userIDKey).(string); ok {
// 使用 userID
}
替代方案：显式参数传递更安全可靠
绝大多数情况下，应该把参数作为函数入参明确定义。这样调用关系清晰、单元测试容易、IDE 能跳转、重构风险低。
- HTTP handler 中，用中间件解析参数后，传给下一层 handler 函数，而不是塞进 context
- 数据库操作函数需要
tenantID？直接加一个tenantID string参数，别依赖 context 查 - 需要跨多层传递？考虑封装结构体（如
RequestParams），比 context 更易追踪
强行用 context 传参，后期一旦某层漏了 set 或 get，错误会静默传播到很深的地方，debug 成本远高于多写几个参数。
常见 panic 场景：类型断言失败没处理
ctx.Value(key) 返回 interface{}，直接强制类型转换（ctx.Value(k).(string)）在 key 不存在或类型不匹配时会 panic。必须用「逗号 ok」语法判断：
v := ctx.Value(myKey)
if s, ok := v.(string); ok {
// 安全使用 s
} else {
// 处理缺失或类型错误，比如返回 error 或用默认值
}
尤其要注意：同一 key 在不同 goroutine 中可能被多次 set，value 类型不一致；或者上游忘记 set，下游直接 panic —— 这类问题在线上很难复现，但发生就是线上事故。
真正需要跨层透传的只有生命周期控制信号。业务参数该在哪层产生，就该由那层明确传下去。context 是开关，不是快递袋。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
