echo.Context非并发安全，不可跨goroutine读写；必须在主goroutine中完成c.Set/c.JSON等操作，异步任务应提取值传参或使用c.Request().Context()并发安全读取。
echo.Context 不是并发安全的，不能跨 goroutine 读写
直接把 c（echo.Context）传给新启动的 goroutine 并调用 c.Get()、c.Set() 或 c.JSON() 是危险的——echo.Context 内部字段（如 echo.context.values）没有加锁，多 goroutine 同时读写会触发 data race。Go 的 go run -race 能立刻捕获这类问题。
常见错误现象：
- handler 中
go func() { c.Set("log_id", "xxx") }()导致 panic 或值丢失 - 异步任务里调用
c.String(200, "ok")，报http: response.WriteHeader on hijacked connection - 多个 goroutine 同时调用
c.Request().Context().Value()，但 key 冲突或断言失败频率异常升高
实操建议：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 只在当前 handler 的主 goroutine 中使用
c的写操作（Set、JSON、String等） - 若需在 goroutine 中访问上下文数据，应提前提取并传参：
logID := c.GetString("log_id"); go doWork(logID) - 绝不要在 goroutine 中调用任何响应写入方法（
c.JSON、c.String、c.File），HTTP 连接此时大概率已关闭
context.Value 可以并发读，但写必须在 request 生命周期内完成
c.Request().Context() 返回的是标准 context.Context，其 Value() 方法是并发安全的读操作；但所有 WithValue() 必须在 handler 执行期间、且仅由主 goroutine 完成——因为中间件链和 handler 是串行的，你无法保证下游 goroutine 启动时机早于 WithValue() 调用。
为什么不能在 goroutine 里调用 context.WithValue(c.Request().Context(), k, v)？
- 生成的新 context 不会自动绑定回
c.Request()，下游 service 层仍取到旧 context - 更严重的是：你修改的是副本，原请求 context 不变，
c.Request().WithContext(newCtx)也只对当前 goroutine 有效 - 若 goroutine 持有该新 context 并传给 DB/Logger，它们拿到的仍是 handler 初始注入的值，不是你后来塞的
实操建议：
- 所有业务凭证（用户 ID、租户 ID、request_id）必须在中间件或 handler 开头就注入
c.Request().Context()，并调用c.SetRequest()更新 - goroutine 中只做
ctx.Value(k)读取，且必须配合类型断言与空值检查 - 避免在 goroutine 中构造新 context 链，尤其不要嵌套
WithValue多层——key 冲突和调试难度会指数上升
别用 c.Set() 代替 context.Value 做跨中间件传递
c.Set() 写入的数据存储在 echo.Context 实例的 map 字段中，它不参与 context 传递，也不被 database/sql、zap、sqlx 等依赖 context 的组件识别。一旦你在中间件 A 里 c.Set("user_id", 123)，中间件 B 或 DB 查询里 c.Get("user_id") 可能返回 nil —— 尤其当 B 没显式调用 c.Get()，或用了第三方库透传原始 context 时。
典型踩坑场景：
- 鉴权中间件用
c.Set("user", u)，日志中间件却从c.Request().Context().Value(userKey)取值 → 日志里 user 字段为空 - DB 层用
db.QueryRowContext(c.Request().Context(), ...)，但审计字段依赖c.Get("tenant_id")→ SQL 日志漏掉租户标识 - 多个中间件依次
c.Set("a", 1)、c.Set("a", 2)，下游取值取决于谁最后执行，行为不可预测
实操建议：
- 统一使用自定义 key 类型 +
context.WithValue()+c.SetRequest()注入，例如：ctx := context.WithValue(c.Request().Context(), userIDKey, u.ID); c.SetRequest(c.Request().WithContext(ctx)) - 定义 key 时用未导出结构体：
type userIDKey struct{}，而非string，避免跨包覆盖 - 禁止在 goroutine 中调用
c.Set()—— 它不是为并发设计的，且值不会透传出去
HTTP handler 返回后，c 和 c.Request().Context() 都可能失效
当 handler 函数 return，Echo 就认为响应已完成，底层 http.ResponseWriter 可能被回收或复用。此时若 goroutine 仍在运行并尝试访问 c 或其 Request().Context()，会出现：panic: http: Handler closed before ResponseWriter.WriteHeader，或 context canceled 错误。
根本原因不是 Context 被 cancel，而是整个 HTTP 连接生命周期结束，关联资源（buffer、conn、timeout timer）已被释放。
实操建议：
- 耗时逻辑必须脱离 HTTP 生命周期：用
asynq、redis queue或带 context timeout 的独立 goroutine（go func(ctx context.Context) { ... }(c.Request().Context())） - 若坚持用裸 goroutine，务必用
context.WithTimeout(c.Request().Context(), 3*time.Second)控制最大执行时间，并检查ctx.Err() - 不要假设
c.Request().Context().Done()信号可靠——它可能比连接关闭晚几毫秒，此时再读写已不安全
c 是一次性的、单 goroutine 绑定对象；而真正可跨层、跨组件、并发安全的只有 c.Request().Context() 的读操作。所有“传值”动作必须前置、单点、强类型，所有“异步”动作必须解耦、带超时、不依赖 c 实例本身。 
