Context取不到值主因是未将新Context挂回*http.Request或用string作key导致匹配失败；context.WithValue返回新对象，原Request.Context指针不变，须显式调用c.SetRequest(c.Request().WithContext(ctx))，且key必须为自定义不可比较类型如type userIDKey struct{}。
Context取不到值，八成是没把新Context挂回*http.Request，或者用了字符串key导致类型断言失败。
为什么c.Request().Context().Value(key)总是nil
因为context.WithValue()返回的是一个全新Context对象，原*http.Request里的Context指针根本没变。Echo中间件里写了ctx := context.WithValue(c.Request().Context(), k, v)，但漏掉最关键的一步：c.SetRequest(c.Request().WithContext(ctx))——这句不执行，下游handler拿到的还是原始Context。
- 漏掉
c.SetRequest()是最高频错误，尤其在自定义日志、DB中间件里反复出现 - 用
c.Set("xxx", v)替代Context传值，看似能取到，但第三方库（如sqlx、zap）压根不认这个，只认Request.Context() - 直接用
string当key，比如context.WithValue(ctx, "user_id", 123)，不同中间件之间极易冲突覆盖
怎么定义安全的Context key
必须用自定义不可比较类型，禁止裸字符串。Go编译器对struct{}和string的key处理完全不同：前者能保证唯一性，后者会因包内重复定义而静默覆盖。
- 正确定义：
type userIDKey struct{}，然后const userIDKeyVar userIDKey = userIDKey{} - 错误写法：
const userIDKey = "user_id"或type userIDKey string（虽能编译，但跨包时可能被其他同名const覆盖） - 取值时务必双判断：
if uid, ok := c.Request().Context().Value(userIDKeyVar).(int); ok { ... }，不能省略ok
中间件链里多个值怎么安全叠加
Context天然支持链式嵌套，但顺序和覆盖逻辑得心里有数。后执行的中间件调用context.WithValue()，会基于前一个中间件返回的Context创建新Context，不会污染上游。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 只要每个中间件都执行了
c.SetRequest(...WithContext(...))，下游就能按顺序拿到所有注入的值 - 如果两个中间件用同一个key（比如都用
userIDKeyVar），后写的会覆盖先写的——这是预期行为，不是bug - 避免在中间件里用
context.WithCancel()或WithTimeout()，除非你明确要控制下游超时；否则应由最外层HTTP server统一设置
调试时怎么快速验证Context是否生效
别靠猜，加一行日志打出来最直接。在handler开头插入：
log.Printf("ctx keys: %+v", c.Request().Context())
但这只能看地址，真要看值得手动打印：
- 临时加断点或日志：
log.Printf("user_id from ctx: %v", c.Request().Context().Value(userIDKeyVar)) - 注意：如果打印出
<nil></nil>，说明key不对或没挂载；如果打印出<not found></not>，说明key对但值没塞进去 - 用
go tool trace或pprof查Context生命周期更重，日常排查优先用日志+断点
真正容易被忽略的是：Context一旦挂载进*http.Request，就绑定到这次HTTP请求的整个生命周期。它不像c.Set()那样只活在Echo Context里——所以别试图在goroutine里异步取Context值，除非你已经用context.WithValue()显式传进去，且确保那个goroutine不会比HTTP请求结束得早。
