c.Set()仅作用于当前Echo.Context，不注入http.Request.Context()，故无法被第三方库感知；必须用context.WithValue()配合自定义key类型写入Request.Context()并调用c.SetRequest()更新，下游统一从c.Request().Context()读取。
为什么c.Set()在中间件间传值经常失效
c.Set()写入的键值对只绑定在当前echo.Context实例上，不会自动透传给后续中间件或handler——除非下游显式调用c.Get()，否则完全不可见。更关键的是，第三方库（比如sqlx.QueryRowContext()、日志器、trace SDK）都依赖http.Request.Context()，而c.Set()根本没动它。
常见错误现象：
- 中间件A调用
c.Set("user_id", "u-123")</li> <li>中间件B里<code>c.Get("user_id")返回nil - DB层调用
sqlx.QueryRowContext(c.Request().Context(), ...)时拿不到user_id，审计日志缺字段
根本原因：两个存储位置互不相干。c.Set()是Echo自己的map缓存；c.Request().Context()是Go标准库的链式上下文，才是跨组件、跨库传递的唯一可信通道。
怎么把值安全塞进c.Request().Context()
必须用context.WithValue()包装，并确保key是自定义类型——不能用string或int字面量，否则极易被其他中间件覆盖或断言失败。
实操步骤：
- 定义私有key类型：
type userIDKey struct{}，再声明var userIDKey userIDKey - 在中间件中获取原始ctx：
ctx := c.Request().Context() - 注入新值：
ctx = context.WithValue(ctx, userIDKey, "u-123") - 更新请求对象：
c.SetRequest(c.Request().WithContext(ctx))（这步漏掉就白做了）
下游handler里取值时，必须用相同key类型断言：if id, ok := c.Request().Context().Value(userIDKey).(string); ok { ... }。别用interface{}硬转，会panic。
哪些值适合放Context，哪些绝对不能放
Context设计初衷是携带请求生命周期内的**不可变元数据**，不是通用状态容器。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
推荐放：
- 用户ID、租户ID、请求ID（
string或int64） - 解析后的JWT payload结构体（如
*User指针） - 灰度标识、渠道标签等轻量字符串
禁止放：
-
map或slice：可能被下游并发修改，引发竞态 - 闭包函数或带状态的对象：Context可能被复制或跨goroutine传递，行为不可控
- 大块二进制数据（如原始body）：内存暴涨，GC压力大
一个容易被忽略的细节：如果你在中间件里改了Context值，但后续又调用了c.Echo().Router().Find()之类会新建子Context的操作，旧值就丢了——得确保所有路径都走同一份更新后的c.Request().Context()。
如何让日志和DB同时拿到中间件注入的值
核心就一条：所有下游组件必须统一从c.Request().Context()读，而不是各自为政。
例如日志中间件要打request_id，就得在记录前确认它已存在于Context中：
func Logger() echo.MiddlewareFunc {
return func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
// 从 Context 取，不是 c.Get()
if reqID, ok := c.Request().Context().Value(reqIDKey).(string); ok {
log.Printf("[req:%s] %s %s", reqID, c.Request().Method, c.Request().URL.Path)
}
return next(c)
}
}
}
DB操作同理：sqlx.QueryRowContext(c.Request().Context(), ...)——只要中间件提前把reqIDKey塞进去了，这里自然能取到。如果某处忘了调c.SetRequest()更新Context，整条链路就断了，且很难定位。
