应使用 c.Set(key, value) 和 c.Get(key) 在 Echo Context 中存取自定义字段，而非直接赋值或滥用标准 context；键名建议加前缀，值类型保持简单；trace ID 等需透传的数据须在中间件生成并 set，在 handler 中类型断言获取；c.Request().Context() 用于控制传播，c.Get() 用于业务数据，二者不可混用。
怎么给 Echo 的 Context 加自定义字段
直接往 echo.Context 里塞字段不行——它是个接口，底层结构体不暴露。正确做法是用 c.Set(key, value) 存，c.Get(key) 取，所有数据都挂载在内部的 map[string]interface{} 上。
常见错误是误以为能像 struct 那样直接点属性：c.UserID 会编译失败；也有人用全局 map 做 context 映射，结果并发时 panic 或漏 cleanup。
-
c.Set("user_id", 123)和c.Get("user_id")是最轻量、最安全的方式 - 键名建议加前缀避免冲突，比如
"myapp.user_id"而不是裸写"user_id" - 值类型尽量保持简单（
int、string、指针），避免存大结构体或带闭包的函数
写一个带日志 ID 的中间件：如何透传请求上下文
典型需求是每个请求生成唯一 trace ID，并在后续 handler 和日志中复用。不能只在中间件里 log 一次就完事，必须让下游也能拿到。
错误做法是把 ID 存到全局变量或本地 goroutine 变量（go 语句里用 context.WithValue 但没传给 echo context）；正确路径是：生成 → c.Set() → 后续 handler 里 c.Get()。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
uuid.NewString()或rand.Int63()生成 ID，别用时间戳——高并发下易重复 - 中间件里调用
c.Set("trace_id", id)，别忘了next(c) - handler 中取值时务必做类型断言：
id, ok := c.Get("trace_id").(string)，ok为 false 说明中间件没跑或 key 写错了
c.Request().Context() 和 c.Get() 有什么区别
两者根本不在一个层面：c.Request().Context() 是 Go 标准库的 context.Context，用于超时控制、取消传播；c.Get() 是 Echo 封装的键值存储，只在当前请求生命周期内有效。
容易混淆的点是：有人想用标准 context 传业务数据（比如用户信息），结果在 handler 里反复 ctx.Value("user") 断言，既难维护又绕过 Echo 的生命周期管理。
- 传控制类数据（deadline、cancel）用
c.Request().Context() - 传业务类数据（用户 ID、权限列表、trace ID）统一走
c.Set()/c.Get() - 不要混用：
c.Request().WithContext(context.WithValue(c.Request().Context(), "x", y))是冗余且无意义的操作
中间件里 panic 了，c.Get() 还能取到值吗
能，只要 panic 发生在 next(c) 之后，或者你用 defer/recover 捕获了——因为 c.Set() 修改的是内存中的 map，panic 不会自动清空它。
但这是个陷阱：如果中间件 A 设置了 "user"，中间件 B panic 了，handler 没执行，但后续 recover 中间件仍可能读到这个 "user"，造成逻辑错乱。
- 敏感数据（如用户权限）建议在最外层中间件设置，在 recover 中间件里主动
c.Set(key, nil)清理 - 避免依赖“中间件执行顺序”来保证数据一致性；更稳妥的是在 handler 开头校验必要字段是否存在
- 测试时故意让某个中间件 panic，然后检查后续
c.Get()是否返回预期值或 nil
