不能用 c.Set() 注入依赖，因其仅限当前 Context 实例且不传递至 request.Context；必须用 context.WithValue() + c.SetRequest() 将依赖注入请求上下文并更新引用，否则 DB 等组件因使用原始空 Context 而 panic。
为什么不能用 c.Set() 注入依赖
因为 c.Set() 只在当前 echo.Context 实例内有效，不参与 Context 链式传递。下游中间件或 handler 若没显式调用 c.Get("xxx")，就完全看不到；更关键的是，第三方库（如 sqlx.QueryRowContext()、zap.Logger.With().Ctx()）只认 c.Request().Context()，对 c.Set() 一无所知。常见错误现象是：中间件里 c.Set("db", db)，handler 里能取到，但 db.QueryContext(c.Request().Context(), ...) 却 panic：context canceled —— 因为 DB 实际用的还是原始空 Context。
必须用 context.WithValue() + c.SetRequest()
注入依赖的唯一可靠路径是把值塞进请求的 Context，并用 c.SetRequest() 更新引用。这一步漏掉，等于白塞。实操要点：
- 定义类型化键：
type ctxKey string，再声明const dbKey ctxKey = "db"（避免字符串键冲突） - 在中间件中获取原 Context：
ctx := c.Request().Context() - 包装新 Context：
newCtx := context.WithValue(ctx, dbKey, yourDBInstance) - 必须更新请求对象：
c.SetRequest(c.Request().WithContext(newCtx))（Echo v4+ 强制要求） - 下游所有组件（DB、logger、cache client）都统一从
c.Request().Context().Value(dbKey)取值
多个中间件依次注入时怎么避免覆盖
Context 是不可变的，每次 context.WithValue() 都返回新实例，不会覆盖旧值。但要注意顺序和 key 冲突：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 如果 A 中间件用
dbKey塞了主库，B 中间件又用同一个dbKey塞了从库，后者会覆盖前者 - 推荐按职责分键：
type dbKey string和const primaryDBKey dbKey = "primary"、const replicaDBKey dbKey = "replica" - 不要在中间件里做耗时操作（如建 DB 连接池），应提前初始化好传入，中间件只负责“绑定”
- 若依赖需按租户隔离（如多租户 DB），键中可嵌入租户 ID：
context.WithValue(ctx, tenantDBKey{tenantID: tID}, db)，此时键类型得是结构体
handler 里安全取值的写法
别直接断言 c.Request().Context().Value(dbKey).(DB)，nil 或类型不匹配会 panic。正确姿势是显式判断：
if db, ok := c.Request().Context().Value(dbKey).(DB); ok {
// 安全使用 db
} else {
return c.JSON(500, echo.Map{"error": "missing database dependency"})
}
类型不匹配比值为空更隐蔽——比如你塞的是 *sql.DB，但取的时候写了 sql.DB（少个指针），就会静默失败。键类型、塞的值类型、取的断言类型，三者必须严格一致。
