“Context has already been set”错误触发于对同一*http.Request实例重复调用WithContext()时，是Go标准库内部校验失败后主动panic，常见于多个中间件或handler中先后执行c.Request = c.Request.WithContext(ctx)。
Context has already been set 错误的触发位置在哪
这个错误不是运行时 panic，而是 http.Request.WithContext() 内部校验失败后主动 panic 的结果。它只在你显式调用 c.Request = c.Request.WithContext(ctx) 且重复设置时触发——注意，是“重复设置”，不是“设置一次”。常见于中间件里手动包装 context 后，又进了另一个也做同样操作的中间件。
典型场景包括：
- 自定义 auth 中间件调用了
c.Request = c.Request.WithContext(authCtx) - 后面又加载了 logger 中间件，它内部也调用了
c.Request.WithContext(logCtx) - 或者你在 handler 里又写了一次
c.Request.WithContext(customCtx)
只要任意两个地方对同一个 c.Request 实例调用了 WithContext()，第二次就会炸。Go 标准库故意这么设计，防止上下文被无意覆盖导致逻辑错乱。
怎么快速定位是哪个中间件/函数干的
别猜，直接加断点或打日志。在所有可能调用 WithContext() 的地方前加一行：
log.Printf("setting context in %s:%d", "middleware.go", 42)
或者更轻量：用 runtime.Caller(1) 动态抓调用栈：
if c.Request.Context() != nil {
_, file, line, _ := runtime.Caller(1)
log.Printf("re-setting context at %s:%d", file, line)
}
这样跑起来一看日志，哪两个文件+行号挨得近、先后出现，基本就是冲突源。尤其注意第三方中间件（比如某些 JWT 插件）是否偷偷做了 context 替换。
另外，Echo 的 echo.Context 接口本身不暴露原始 *http.Request 是否已被设过 context，所以不能靠 c.Request.Context() == nil 来判断——它可能已经被设过但没出错，也可能设过一次后你再设就崩。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
安全替换 Context 的唯一正确姿势
必须确保整个请求生命周期内，c.Request 只被 WithContext() 赋值一次。推荐做法是：
- 只在最外层中间件（比如第一个注册的 auth 或 trace 中间件）里做
c.Request = c.Request.WithContext(...) - 后续中间件一律用
c.Request.Context()读取，不再写入 - 如果必须注入新 context（比如跨服务 traceID 更新），用
context.WithValue()基于已有 context 衍生，而不是重设整个c.Request - 绝对不要在 handler 函数里再调用
c.Request.WithContext()—— 这是最常踩的坑
如果你确实需要多个 context 层级（比如 auth + trace + metrics），全部基于初始 context 衍生，最后统一塞回 c.Request 一次即可：
baseCtx := c.Request.Context() authCtx := context.WithValue(baseCtx, authKey, user) traceCtx := context.WithValue(authCtx, traceKey, spanID) c.Request = c.Request.WithContext(traceCtx) // ← 只有这一行
为什么 pprof/goroutine 里看不到 Context 相关线索
/debug/pprof/goroutine?debug=2 输出里几乎不会出现 WithContext 字样，因为 panic 发生在函数调用栈深处，且是立即终止的。你看到的往往是 net/http.serverHandler.ServeHTTP 或 echo.(*Echo).ServeHTTP 下某一层匿名函数，根本看不出哪行代码惹的祸。
真正有用的线索藏在 panic 日志里——默认 Echo 会把 panic 打到 stderr，格式类似：
panic: Context has already been set
goroutine 123 [running]:
net/http.(*Request).WithContext(0xc0004a8000, {0x...})
...
关键看第三行：它明确指出是 net/http.(*Request).WithContext 报的错，说明问题一定出在你自己写的代码里，而非 Echo 框架内部。这时候立刻 grep 全项目：grep -r "WithContext" . --include="*.go"，再逐个检查调用点是否守规矩。
容易被忽略的是：有些工具函数（比如封装的 DB 查询、HTTP 客户端调用）也会悄悄接收并重设 *http.Request，它们不在中间件或 handler 里，但一样危险。
