应将参数存入c.request().context()而非c.set()，因context支持跨中间件链式传递且类型安全；需用context.withvalue()配合自定义键类型包装，并调用c.setrequest()更新请求上下文。
中间件里怎么把参数塞进c.Request().Context()
直接往 Context 里存值是最稳妥的做法，Echo 的 c.Set() 只作用于当前请求生命周期，但不跨中间件传递（除非显式调用 c.Get()），而 Context 支持链式传递且类型安全。别用全局变量或闭包捕获，那会引发并发问题。
实操建议：
- 在中间件中用
c.Request().Context()获取原始上下文，再通过context.WithValue()包装新键值对 - 键必须是自定义类型（比如
type ctxKey string），避免字符串键冲突 - 下游 handler 里统一用相同键名从
c.Request().Context()取值，不要依赖c.Get()
示例键定义：
type ctxKey string<br>const userIDKey ctxKey = "user_id"
为什么不能只用c.Set()传用户ID、租户ID这类公共参数
c.Set() 写入的数据仅对当前 Echo context 生效，且不会自动透传给后续中间件——如果下一个中间件没调用 c.Get("xxx")，它就完全看不到。更麻烦的是，一旦你用了第三方库（比如数据库 ORM）需要从 Context 拿用户信息做审计日志，c.Set() 就彻底失效了。
常见错误现象：
- 中间件 A 调用
c.Set("tenant_id", "t-123")，中间件 B 里c.Get("tenant_id")返回nil - handler 里能取到值，但调用
sqlx.QueryRowContext(c.Request().Context(), ...)时，DB 层拿不到 tenant_id
如何让logger和DB都拿到中间件注入的request_id
关键不是“怎么塞”，而是“塞到哪”：必须塞进 c.Request().Context()，并且确保所有下游组件都用这个 Context 发起调用。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
实操要点：
- 中间件中生成
request_id后，用context.WithValue(c.Request().Context(), requestIDKey, rid)创建新 Context - 调用
c.SetRequest(c.Request().WithContext(newCtx))替换原 Request 的 Context（这是 Echo v4+ 必须步骤） - 日志库（如 zap）需通过
c.Request().Context().Value(requestIDKey)提取；DB 查询必须用db.QueryContext(c.Request().Context(), ...)
漏掉 c.SetRequest() 是最常踩的坑——值塞进去了，但 Request 还指着旧 Context。
多个中间件依次注入参数时要注意什么
Context 是不可变的，每次 WithValue 都返回新实例，所以顺序很重要：后执行的中间件看到的是前一个中间件包装过的 Context。
典型场景（按注册顺序）：
- AuthMiddleware → 解析 token，写入
user_id - TenantMiddleware → 读
user_id查租户，写入tenant_id - TraceMiddleware → 读
tenant_id和user_id构建 trace tag
如果 TenantMiddleware 在 AuthMiddleware 前执行，它就拿不到 user_id。Echo 中间件执行顺序严格按 e.Use(...) 注册顺序，不是路由匹配顺序。
真正容易被忽略的是 Context 键类型的唯一性——两个中间件如果都用 string("user_id") 当键，其中一个会覆盖另一个。务必定义私有类型，哪怕只是 type userIDKey struct{}。
