Echo中c.Set()不能跨中间件传递值，因仅限当前c实例可见；需用context.WithValue()写入request.Context并调用c.SetRequest()更新，且key须为私有类型以避免冲突。
echo.Context.Set() 不能跨中间件传递值
直接调用 c.Set("user_id", 123) 写入的值，只在当前中间件或 handler 的 c 实例中可见；下游中间件调用 c.Get("user_id") 取不到——除非你显式调用它，且上一个中间件没覆盖同名 key。更麻烦的是，第三方库（比如数据库 ORM 的审计日志）压根不认 c.Get()，它们只从 http.Request.Context() 拿数据。
常见错误现象：c.Get("tenant_id") 在鉴权中间件里能取到，但在日志中间件里返回 nil；或者 ORM 日志里 tenant 字段始终为空。
- 别把
c.Set()当全局变量用，它不是 context 传递机制 - 如果必须用
c.Set()，仅限于同一 handler 内部短生命周期的数据暂存（比如模板渲染前临时加个 flag） - 所有需要透传到 service/DAO 层、或被其他中间件消费的业务元数据（如
user_id、tenant_id、request_id），必须走context.WithValue()
往 request.Context 里塞值必须用自定义 key 类型
写 context.WithValue(r.Context(), "user_id", u) 是危险操作：字符串 key 容易跨包冲突，多个中间件都用 "user_id" 就会互相覆盖，取值时类型断言还可能 panic。
正确做法是定义未导出空 struct 作 key：
type userCtxKey struct{}
var userKey = userCtxKey{}
然后在中间件中：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
ctx := context.WithValue(c.Request().Context(), userKey, u) c.SetRequest(c.Request().WithContext(ctx))
- key 必须是私有类型（不导出），不能是
string、int或导出类型 - 务必调用
c.SetRequest()更新请求对象，否则下游拿到的还是旧 context - 下游统一用相同 key 提取：
u, ok := c.Request().Context().Value(userKey).(User)，必须检查ok
不要用 context.Value 传可变对象或大结构体
context.Value 设计初衷是传轻量、只读的请求元数据（如 ID、traceID、语言偏好）。传 *map[string]string 或带指针字段的 struct，一旦被下游修改，上游逻辑可能意外失效，且极易引发 data race。
典型踩坑场景：中间件 A 注入 ctx.Value(reqMetaKey{}, &reqMeta{Lang: "zh"})，中间件 B 改了 Lang 字段，handler 里再取就不是原始值了。
- 值应为不可变类型：基本类型、小 struct（字段全为基本类型）、或只读接口（如
io.Reader） - 多字段建议打包成不可变 struct 单次注入，而不是链式调用多次
WithValue - 绝不要传 slice、map、chan、函数或带 mutex 的 struct
HTTP handler 中取 context 值必须封装校验函数
在 handler 里裸写 c.Request().Context().Value(userKey{}).(User) 是高危行为：类型断言失败直接 panic，key 不存在时返回 nil，但没人检查就直接 dereference，线上崩得毫无征兆。
应该统一提供提取函数：
func UserFromCtx(ctx context.Context) (*User, bool) {
u, ok := ctx.Value(userKey{}).(*User)
return u, ok && u != nil
}
- 每个业务 key 都配一个提取函数，强制做非空 + 类型双检
- 函数名体现语义（
UserFromCtx而非GetUser），避免和 ORM 方法混淆 - 提取失败时，根据场景返回 error 或 fallback 默认值，绝不静默忽略
实际项目中最容易被忽略的一点：**context key 的定义位置和可见性**。很多人把 userKey 定义在 middleware 包里，结果 service 层 import 不到，只能自己再造一个同名 key——这等于没防住冲突。key 应该定义在 shared 或 types 包中，作为整个服务的契约一部分。
