中间件中读取请求头需用c.request().header.peek("x-trace-id")并转string，修改用c.request().header.set()；/api无法匹配/api/v1/login，应改用/app.use("/api/", middleware)或全局挂载后路径判断；注入头需先检查是否存在再设，转发x-forwarded-for应用add而非set；中间件顺序决定头可见性，先注册先执行。
中间件里怎么读取和修改请求头
请求头在 c.Request().Header 里，不是 c.Get() 或 c.Query() 能拿到的。常见错误是想用 c.Get("X-Trace-ID") 读自定义头——它只对标准头（如 User-Agent）做大小写归一化，自定义头必须用 c.Request().Header.Peek("X-Trace-ID")，返回的是 []byte，需要 string() 转换。
修改请求头要调 c.Request().Header.Set()，不是 c.Set()（那是设响应头）。设完不会自动透传给下游 handler，但如果你在中间件里改了，后续所有 handler 都能通过 c.Request().Header 看到新值。
- 不要在中间件里反复
Peek同一个头，性能差；建议一次读出存到c.Locals -
Peek返回 nil 表示头不存在，别直接string(nil)，会 panic - 若需兼容大小写变体（如
X-Trace-Id和x-trace-id），得自己遍历c.Request().Header所有键
为什么 app.Use("/api", middleware) 无法拦截 /api/v1/login 的请求头
因为 app.Use("/api", ...) 匹配的是路径前缀，且要求严格边界：/api 能匹配 /api 和 /api/，但不匹配 /api/v1/login —— 注意，/api 后面没接 /，所以 /api/v1/login 的前缀是 /api/，不是 /api。这是 Fiber 的前缀匹配规则决定的，不是 bug。
解决办法只有两个：
- 把挂载点改成
app.Use("/api/", middleware)，这样 /api/v1/login 就能命中 - 或者用根路径全局挂载：
app.Use(middleware)，再在中间件里用c.Path()判断是否以/api开头
别依赖 StrictRouting: false 来绕过，它影响的是路由匹配，不改变 Use 的前缀判定逻辑。
如何安全地注入或覆盖请求头（比如加 TraceID、转发 X-Forwarded-For）
注入 TraceID 常见做法是在中间件开头生成并塞进 c.Request().Header，但要注意：如果上游已带 X-Request-ID，应优先复用，而不是覆盖——否则链路会断。Fiber 不提供“只在缺失时设”的原子操作，得手动判断：
if len(c.Request().Header.Peek("X-Request-ID")) == 0 {
id := uuid.New().String()
c.Request().Header.Set("X-Request-ID", id)
}
转发 X-Forwarded-For 更容易踩坑：
- 别直接
c.Request().Header.Set("X-Forwarded-For", ...)，这会覆盖原始值，应追加：c.Request().Header.Add("X-Forwarded-For", ip) - 注意 Nginx 或 Cloudflare 可能已设该头，重复添加会导致 IP 链过长，后端解析失败
- 真实客户端 IP 应从
c.IP()拿，不是从头里硬解析字符串
中间件顺序错乱导致请求头丢失或覆盖
请求头修改是原地生效的，中间件 A 改了头，B 才能读到；但如果 B 在 A 之前注册，B 就读不到 A 写的值。Fiber 中间件执行顺序完全由 app.Use() 的调用顺序决定，先注册的先执行。
典型冲突场景：
- 你写了鉴权中间件（读
Authorization头）和日志中间件（也读这个头打日志），但日志中间件注册在鉴权前面 → 日志里可能打空 Authorization - 多个中间件都往
X-Trace-ID写值，后注册的会覆盖先注册的
真正关键的点是：**头的读写本身不阻塞，但顺序错了，下游 handler 就拿不到预期值**。调试时可在每个中间件开头加 log.Printf("middleware %s: auth=%s", name, string(c.Request().Header.Peek("Authorization"))) 快速定位哪一层被清空或覆盖。
