正确做法是先用context.WithValue生成新ctx，再用c.Request().WithContext()创建新req，最后调c.SetRequest(req)；c.Set()不跨goroutine，异步操作必须用context值；自定义Context需首个注册；WebSocket升级后context断裂，须手动透传。
中间件里用 context.WithValue 传数据，但必须重设 Request.Context
直接对 c.Request().Context() 调用 context.WithValue 不会生效——因为 Echo 的 echo.Context 内部持有的是原始 *http.Request，而 Go 的 http.Request.WithContext 返回的是新请求对象，旧对象不变。不重设会导致下游 handler 仍读到空 context。
正确做法是两步：先生成带值的新 context，再用 c.Request().WithContext() 创建新 request，最后调用 c.SetRequest() 替换当前 request：
ctx := context.WithValue(c.Request().Context(), traceKey{}, "abc123")req := c.Request().WithContext(ctx)-
c.SetRequest(req)← 这一步漏掉就白干
别把 c.Set() 当 context 用，跨 goroutine 会丢数据
c.Set("key", value) 只在当前请求生命周期内有效，且仅限于当前 goroutine。一旦你启了协程（比如异步发消息、调下游服务），c.Set() 里的值就不可见了——它不随 goroutine 传播，也不进 context。
真正能跨 goroutine 传递的只有 c.Request().Context() 里的值。所以：
- 需要异步操作时，必须从
c.Request().Context()取值，而不是c.Get()或c.Get("key") -
c.Set()仅适合快速存取、纯同步场景（如模板渲染前塞个用户昵称） - 如果同时用了
c.Set()和context.WithValue，建议 key 名区分，避免混淆（比如"trace_id"vstraceKey{}）
自定义 Context 类型更安全，但 middleware 注册顺序不能错
想加方法（比如 c.TraceID() 或 c.UserID()），可以扩展 echo.Context 接口。但注意：自定义类型必须包装原 echo.Context，且中间件注册要在所有其他中间件之前，否则后续中间件拿到的还是原始 echo.Context 实例。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
常见错误是把自定义中间件放在 e.Use(authMiddleware) 后面，结果 auth 里用的还是原生 c，无法调 c.TraceID()。
示例关键点：
- 定义
type CustomContext struct { echo.Context }并实现方法 - 中间件里写
cc := &CustomContext{c}; return h(cc) -
e.Use(customContextMiddleware)必须是第一个e.Use()
WebSocket 升级后 context 会断，得手动透传
Echo 的 websocket.Connect 是对 gorilla/websocket.Upgrader.Upgrade 的薄封装，升级完成后原 echo.Context 生命周期结束，新连接的 *websocket.Conn 不携带任何 context 数据。
如果你在升级前通过 context 存了 userID 或 traceID，必须在 upgrade 前取出，显式传给后续 WebSocket 处理逻辑：
- 在 upgrade handler 开头就读取
c.Request().Context().Value(userIDKey) - 把值作为参数传给
handleWSConn(conn *websocket.Conn, userID string) - 不要指望 upgrade 后还能从 conn 反查到 echo.Context 或它的 context
这个断裂点容易被忽略，尤其在做链路追踪或权限校验时，一断就难定位。
