应定义强类型 CustomContext 结构体嵌入 echo.Context，用指针接收器封装业务字段与方法；中间件须最先注册并传 *CustomContext 给 next()；handler 中显式断言类型；敏感字段提供带兜底的 getter；trace_id 等需日志透传的数据通过 CustomContext 桥接。
怎么用 CustomContext 封装并安全扩展 echo.Context
直接在 c.Set() 里塞任意 key-value 是最常见也最危险的做法：类型不安全、拼写错误无提示、IDE 不识别、重构时极易漏改。真正可维护的扩展方式是定义强类型子结构，把业务上下文数据作为字段封装进自定义 context 类型。
关键点在于：CustomContext 必须嵌入原始 echo.Context，且中间件注册顺序必须在所有其他中间件之前，否则后续中间件拿到的仍是原生 echo.Context 实例。
- 定义结构体时用指针接收器，避免值拷贝导致
echo.Context方法调用失效 - 中间件中构造
*CustomContext后，必须原样传给next(c)，不能只传c（否则下游收不到） - handler 中需显式类型断言：
cc := c.(*CustomContext)，否则编译不通过
示例：
type CustomContext struct {
echo.Context
}
func (c *CustomContext) UserID() uint64 {
if id, ok := c.Get("user_id").(uint64); ok {
return id
}
return 0
}
// 中间件必须最先注册
e.Use(func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
cc := &CustomContext{c}
return next(cc)
}
})
为什么不能只靠 c.Set() 和 c.Get() 传业务数据
c.Set() 看似简单，但实际埋了三个坑：key 是字符串，拼错就静默失败；value 是 interface{}，取值时要手动断言，一旦类型不符 panic；没有编译期检查，测试覆盖不到就上线出错。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
比如你写了 c.Set("user_id", 123)，但在 handler 里写成 c.Get("user_idd") 或 c.Get("user_id").(string)，运行时才暴露问题。
- 所有需要跨中间件/Handler 传递的业务上下文数据，都应抽象为 CustomContext 的方法，而非裸 key
- 敏感字段（如 user_id、tenant_id）建议封装 getter 并加默认兜底，避免空指针或类型 panic
- 不要在多个中间件里反复
c.Set()同一个 key——CustomContext 初始化一次就够了
如何让 CustomContext 支持日志透传 trace_id
分布式日志要求每条日志带 trace_id，但 echo.Logger 不感知 echo.Context。CustomContext 是唯一能自然桥接两者的载体：你在中间件里从请求头提取 trace_id，存进 CustomContext 字段；再在自定义 logger 的 Output() 方法里，通过 c.(CustomContext).TraceID() 拿到它。
- 别试图在
Output()里调c.Get()——echo.Logger.Output()参数只有io.Writer和string，根本没echo.Context - CustomContext 的
TraceID()方法应优先读c.Request().Context().Value()（兼容 OpenTelemetry）， fallback 到c.Get() - 如果用了
middleware.RequestID，它的 ID 已存于c.Get("request-id")，可直接复用
CustomContext 和中间件透传数据的边界在哪
CustomContext 适合放**稳定、高频、跨层共用**的数据，比如 user_id、tenant_id、trace_id；而临时、单次、低频数据（如校验后的 token payload、解析后的 query 参数）仍该走 c.Set() + 显式清理，避免 CustomContext 膨胀成万能桶。
一个容易被忽略的事实：CustomContext 实例生命周期 = 单次请求，它本身不增加内存压力；但如果你在里面缓存大对象（如未序列化的 DB 结果），就可能引发 GC 延迟。
- CustomContext 字段只存 ID、状态码、开关标志等轻量值，重数据用局部变量或 service 层传参
- 所有 setter 方法（如
SetTenantID()）应在 auth 中间件里完成，handler 只读不写 - 别在 CustomContext 里嵌套另一个 context.Context——会造成双 context 管理混乱
