Revel 中设置响应头必须使用 c.Response.Out.Header().Set()，因 c.Response.Header() 返回只读副本；需在 FlashFilter 和 SessionFilter 之前通过自定义 Filter 注入，且不可在 Action 中调用。
Revel 框架本身不提供类似 res.setHeader() 或 response.headers.append() 这样的高层封装接口，设置响应头必须走底层 http.ResponseWriter，且时机很关键——只能在写入响应体之前操作，否则会静默失效或触发 panic。
用 Filter 中间件统一注入 Header
Revel 的 Filter 是最自然、最可控的入口点。所有请求都经过过滤器链，你可以在 RouterFilter 之后、ActionInvoker 之前插入自定义逻辑，直接操作 c.Response.Out 对应的 http.ResponseWriter。
- 不要在 Controller 的 Action 方法里调用
c.Response.Out.Header().Set()—— 此时可能已开始写 body，Header 已被发送 - 推荐在
app/filters.go的var Filters = []Filter{...}中插入自定义 filter，位置建议在ParamsFilter和SessionFilter之间 - 示例代码中必须用
c.Response.Out.Header().Set()（不是c.Response.Header().Set()），因为 Revel 的*Response封装不暴露原生 Header 接口
为什么 c.Response.Header().Set() 无效？
Revel 的 app.Response 类型是框架自定义结构，它的 Header() 方法返回的是一个只读副本（内部是 map[string][]string 的浅拷贝），任何修改都不会反映到底层 http.ResponseWriter 上。真正生效的只有 c.Response.Out.Header().Set()，它直连标准库的响应对象。
- 常见错误：写
c.Response.Header().Set("X-Trace-ID", uuid)，运行无报错但响应里看不到该 header - 正确写法：
c.Response.Out.Header().Set("X-Trace-ID", uuid) - 若需追加多个同名 header（如
Set-Cookie），用Add()而非Set()
安全头与反向代理场景下的注意事项
如果你用 Nginx 做反向代理（生产环境强烈推荐），Revel 应用只监听 127.0.0.1:8089，那么安全类响应头（如 X-Frame-Options、Content-Security-Policy）更适合由 Nginx 统一设置，而不是在 Revel 里重复添加。
- Nginx 配置中用
add_header always确保覆盖上游响应，避免被 Revel 的 header 冲突或遗漏 - Revel 中设置的业务相关 header（如
X-Request-ID、X-RateLimit-Remaining）仍应保留在应用层，便于日志追踪和限流逻辑耦合 - 注意：Nginx 默认不传递某些 header（如带下划线的），若需透传，要显式配置
underscores_in_headers on;
最易被忽略的一点：Revel 的 FlashFilter 和 SessionFilter 会在响应结束前自动写入 cookie，它们内部会调用 http.SetCookie()，这会触发底层 WriteHeader()。一旦发生，后续任何 Header().Set() 都会失效。所以自定义 header 的 filter 必须排在这两个 filter 之前。
