中间件里改请求头必须用ctx.Request().Header.Set()，因HTTP请求头可写且修改后对后续handler生效；ctx.Header()只影响响应头，ctx.Set()仅存上下文变量，二者均不改变真实请求头。
中间件里改请求头必须用 ctx.Request().Header.Set()
HTTP 请求头是只读的（http.Header 类型），但 Iris 的 ctx.Request() 返回的是标准 *http.Request，它的 Header 字段可写。直接调用 ctx.Request().Header.Set("X-Trace-ID", "abc123") 就能生效，后续 handler 或中间件都能读到新值。
常见错误是误用 ctx.Header() —— 这个方法只影响响应头，对请求头完全无效。也别试图改 ctx.Request().Host 或 ctx.Request().URL，这些字段修改后不会被路由系统识别，还可能破坏路径解析。
-
ctx.Request().Header.Set()是唯一可靠方式，支持重复调用覆盖旧值 - 若需删除某个请求头，用
ctx.Request().Header.Del("X-Forwarded-For") - 注意大小写不敏感：Set("x-forwarded-for") 和 Set("X-Forwarded-For") 效果相同
- 修改发生在当前请求生命周期内，不影响其他请求，也不污染 goroutine
为什么不能在中间件里用 ctx.Set() 传请求头？
ctx.Set() 存的是键值对到当前上下文的内部 map，它和 HTTP 头完全无关。你写 ctx.Set("trace_id", "abc123")，后续 handler 可以用 ctx.Get("trace_id") 拿到，但这对 ctx.GetHeader("X-Trace-ID") 没有任何影响。
很多开发者混淆了「上下文变量」和「HTTP 头字段」——前者是框架内部传递数据的机制，后者是网络协议层的真实字段。如果下游服务（比如反向代理、日志网关）依赖特定请求头做路由或审计，必须走 Header.Set()，否则它们根本收不到。
-
ctx.Set()适合传结构体、中间计算结果、用户身份对象等非协议数据 -
ctx.Request().Header才是真正发给下游 HTTP 服务的原始头信息 - 两者混用会导致调试困难：curl -v 看不到你“以为设了”的头
修改 Host 头要特别小心
Host 是特殊请求头，Iris 路由器在匹配前会先检查它。如果你在中间件里强行改 ctx.Request().Header.Set("Host", "api.example.com")，可能导致路由找不到对应 Party 或子域名分组，返回 404。
正确做法是：需要 Host 重写时，优先用 app.SubdomainRedirect() 或 Nginx 做前置处理；真要在代码层干预，必须确保 ctx.Request().Host 同时更新（虽然这不推荐），且所有相关路由都注册在对应 Party 下。
- Host 头修改不是“设了就完事”，它直接影响
app.Party("api.")和app.Subdomain("api")的匹配逻辑 - 测试时用 curl -H 'Host: api.example.com' http://localhost:8080/ 模拟，别只靠浏览器访问
- 本地开发若改 Host，记得同步改
/etc/hosts，否则 DNS 解析失败
修改后如何验证是否生效？
最直接的方式是在下一个中间件或 handler 里打印出来：fmt.Printf("X-Trace-ID: %s\n", ctx.GetHeader("X-Trace-ID"))。但要注意：如果中间件链里有 recover 中间件，panic 后的恢复流程可能绕过你设的头，所以验证点最好放在紧接其后的 handler 里。
更可靠的验证是抓包：启动服务后用 curl -v http://localhost:8080/test，看 > 部分有没有你设的请求头。或者加一个透传下游的代理 handler：
app.Any("/proxy", func(ctx iris.Context) {
fmt.Printf("Request headers: %+v\n", ctx.Request().Header)
ctx.Next()
})
- 别依赖
ctx.GetHeader()在同一个中间件里立刻读取刚 set 的值——它底层是 map 查找，没问题，但容易形成“我以为设了”的错觉 - 跨中间件传递时，
ctx.GetHeader()是唯一标准读法，不是ctx.Request().Header.Get()（虽然结果一样，但语义不清） - 生产环境别打全量 header 日志，避免泄露敏感字段如 Authorization
实际修改请求头这件事本身很简单，难的是意识到它会影响整个请求生命周期里的所有环节——从路由匹配、中间件顺序，到下游服务行为。很多人卡在“设了但没生效”，其实只是没搞清 ctx.Header() 和 ctx.Request().Header 的根本区别。
