Echo中间件通过c.Request().Header.Get()读取、c.Response().Header().Set()写入自定义Header；注意Header名大小写不敏感但需用规范格式，请求头不可修改原值，应使用c.Set()/c.Get()透传，响应头写入须在c.Next()前后且避免并发覆盖。
中间件里怎么读取和修改自定义 Header
Echo 的中间件本质是 echo.MiddlewareFunc，接收 c echo.Context，所有 Header 操作都通过 c.Request().Header（读）和 c.Response().Header()（写）完成。注意：HTTP Header 名不区分大小写，但 Go 的 http.Header 内部用规范化的 key（如 X-Request-Id 会被存为 X-Request-Id），所以用原始拼写读写最稳妥。
常见错误是直接改 c.Request().Header.Set() —— 这只能影响后续读取，无法改变已进入路由逻辑的请求状态；真正要“处理”自定义 Header，多数场景是校验、透传或注入响应头：
- 校验：
c.Request().Header.Get("X-Api-Key")取值，为空或非法时调c.AbortWithStatusJSON(401, ...) - 透传：把
X-Forwarded-For提取后存入 context：c.Set("client-ip", c.Request().Header.Get("X-Forwarded-For")) - 注入响应头：
c.Response().Header().Set("X-Processed-By", "auth-middleware")，注意必须在c.Next()前或后，但不能在c.Next()中间打断
为什么 c.Request().Header.Add() 不生效
因为 http.Request.Header 是只读快照——Echo 在解析完请求后就冻结了它。调用 Add() 或 Set() 实际操作的是副本，不影响底层连接或后续中间件对原始 Header 的读取。如果你需要“覆盖”某个 Header 值供下游使用，正确做法是：
- 用
c.Set("header-x-token", value)存到 Echo Context 中，下游 handler 用c.Get("header-x-token")取 - 若必须让下游标准库代码（比如某个依赖
http.Header的工具函数）感知新值，得用c.Request().WithContext(...)注入自定义context.Context并携带数据，但这是侵入式方案，不推荐 - 想统一改所有出站响应头？直接在中间件末尾用
c.Response().Header().Set()即可，这个是真实生效的
带前缀的自定义 Header 被 Nginx 或 Cloudflare 丢弃怎么办
很多反向代理默认过滤掉非标准 Header，尤其是不含 X- 前缀或含下划线（_）的字段。例如你设了 Authorization-Token，Nginx 可能直接不转发。解决方法分两端：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- Nginx 配置里加：
proxy_pass_request_headers on;和underscores_in_headers on;（如果用了下划线），再显式放开：proxy_set_header X-Auth-Token $http_x_auth_token; - Cloudflare 默认屏蔽所有非标准 Header，必须用 Page Rule + “Custom Cache Key” 或 Workers 注入，或者改用它允许的前缀如
Cf-*、X-* - Echo 侧别用
Set()写空值，比如c.Response().Header().Set("X-Trace-ID", "")会发一个空头，某些代理可能报错；应先Get()判空再决定是否Set()
多个中间件顺序导致 Header 冲突的典型场景
比如你写了两个中间件：一个做鉴权（读 X-Api-Key），另一个做日志（读 X-Request-ID）。如果鉴权中间件里调了 c.Abort()，日志中间件就不会执行 —— 但如果你在日志中间件里提前写了 c.Response().Header().Set("X-Log-ID", ...)，而鉴权失败返回 401，这个头依然会发出，造成误导。
更隐蔽的问题是并发写响应头：多个中间件同时调 c.Response().Header().Set("X-RateLimit", "...")，最后生效的是最后一个。避免方式：
- 响应头写入尽量集中，比如只在最外层中间件或统一的 response wrapper 里做
- 用
Get()先检查是否已设置，再决定是否Set()，尤其对X-Content-Type-Options这类安全头 - 不要在
c.Next()后再读c.Response().Status()来动态写头 —— 此时 response body 可能已 flush，Header 写入会 panic
Header 处理看着简单，但跨代理、多中间件、读写时机这几个点叠在一起，最容易在压测或上线后才暴露问题。动手前先确认你的网关是否透传、中间件是否 Abort、响应头是否被重复覆盖——这三处查一圈，90% 的 Header 相关异常就定位完了。
