在Iris中用ctx.Header()设置响应头最常用且可靠，会覆盖同名头并适用于所有响应类型；需在ctx.Next()前后调用，不可在ctx.StopExecution()之后；常用于静态值、动态值、缓存控制及全局安全头注入。
在 Iris 中用 ctx.Header() 设置响应头
直接调用 ctx.Header() 是最常用、最可靠的方式，它会覆盖同名已有头（如果存在），且对所有响应类型生效（JSON、HTML、Protobuf 等）。注意：必须在 ctx.Next() 之前或之后调用，但不能在 ctx.StopExecution() 之后——否则响应已终止，写入无效。
常见错误现象：头没生效、被后续中间件或处理器覆盖、OPTIONS 请求里缺失 Access-Control-Allow-Headers 导致预检失败。
-
ctx.Header("X-App-Version", "v1.2.3")—— 静态值，适合版本标识 -
ctx.Header("X-Request-ID", ctx.GetID())—— 动态值，需确保上下文未过期 -
ctx.Header("Cache-Control", "public, max-age=3600")—— 控制 CDN 或浏览器缓存
全局响应头用 app.UseGlobal() 统一注入
如果你需要为所有路由（包括静态文件）都加一组固定头，app.UseGlobal() 比每个路由单独写更安全。但它不拦截 Iris 内置的静态文件处理器（如 app.HandleDir()），除非你显式启用 iris.WithoutVersionChecker 等选项并自行接管静态服务。
使用场景：统一添加安全头（X-Content-Type-Options、X-Frame-Options）、监控头（X-Response-Time）。
- 必须放在
app.Listen()之前，且早于任何Use()或路由注册 - 中间件函数仍需是
func(ctx iris.Context)类型，并调用ctx.Next() - 避免在
UseGlobal中写耗时逻辑，它会影响所有请求（含 favicon.ico、/health 等）
CORS 场景下要区分 OPTIONS 和实际请求
单纯设置 Access-Control-Allow-Origin: * 不足以让跨域 POST/PUT 带认证头的请求通过；浏览器会在真正请求前发一个 OPTIONS 预检，此时必须返回对应 Allow 头，且状态码应为 204（无响应体）。
容易踩的坑：忘记处理 OPTIONS、在预检响应里写了 ctx.JSON()（导致 200 + body，违反 CORS 规范）、Allow-Headers 漏掉 Authorization 或自定义头。
- 检查
ctx.Method() == "OPTIONS"后立即设置头并调用ctx.StatusCode(204)，然后return -
Access-Control-Allow-Headers必须精确匹配前端实际发送的头名（大小写敏感） - 若后端需读取
Cookie或Authorization，Access-Control-Allow-Origin不能为*，得写具体域名
模板渲染时响应头可能被覆盖
当使用 ctx.View() 渲染 HTML 模板时，Iris 默认会设置 Content-Type: text/html; charset=utf-8。如果你提前用 ctx.Header("Content-Type", ...) 设置了别的值（比如 application/json），它会被模板引擎重置——这不是 bug，而是设计行为。
解决办法只有两个：要么放弃 ctx.View() 改用 ctx.Write() 手动输出 HTML 字符串；要么接受默认头，把自定义头限定在非模板路径（如 API 接口）。
性能影响很小，但逻辑上容易混淆：你以为设了头，结果浏览器看到的是框架自动写的那个。
