Buffalo框架默认不自动设置安全响应头，需通过buffalo.WrapHandler全局注入或在handler内手动设置，且必须确保设置时机早于响应写入。
Buffalo 框架默认不自动设置常见响应头（如 Content-Security-Policy、X-Frame-Options、Strict-Transport-Security），必须显式配置中间件或在 handler 中手动写入。
使用 buffalo.WrapHandler 注入通用响应头
这是最推荐的方式，适合全局统一设置（如安全头、缓存策略）。Buffalo 基于 net/http，可直接包装底层 http.Handler：
- 创建一个标准
http.Handler包装器，在ServeHTTP中修改w.Header() - 用
buffalo.WrapHandler将其转为 Buffalo 中间件 - 注意：必须在
app.Use()中尽早注册（比如在app.Use(middleware.PopTransaction(app.DB))之前），否则可能被后续中间件覆盖
func SecurityHeaders(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("X-Frame-Options", "DENY")
w.Header().Set("X-Content-Type-Options", "nosniff")
w.Header().Set("X-XSS-Protection", "1; mode=block")
w.Header().Set("Strict-Transport-Security", "max-age=31536000; includeSubDomains")
next.ServeHTTP(w, r)
})
}
// 在 actions/app.go 中
app.Use(buffalo.WrapHandler(SecurityHeaders))
在 action handler 内部手动设置响应头
适用于动态、路由级定制（如根据用户角色设 Cache-Control 或返回自定义 X-RateLimit-Remaining）：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 直接调用
c.Response().Header().Set()，必须在c.Render()或c.String()之前执行 - 若使用
c.Render()，且模板中已触发 write（如text/html自动写 status 200），再设 header 可能无效 —— Buffalo 不会报错，但浏览器收不到 - 对 JSON 接口，建议搭配
c.JSON()使用，并在调用前设 header
func MyHandler(c buffalo.Context) error {
c.Response().Header().Set("Cache-Control", "private, max-age=60")
c.Response().Header().Set("X-App-Version", "v1.2.3")
return c.JSON(200, map[string]string{"status": "ok"})
}
避免 Content-Length 冲突导致 gzip 失效
Buffalo 默认不启用 gzip，但如果搭配 gorilla/handlers.CompressHandler 使用（常见于生产部署），手动设置 Content-Length 会导致压缩失败或响应截断：
- 绝不要手动调用
w.Header().Set("Content-Length", ...) - Buffalo 的
c.Render()和c.JSON()会自动计算并写入Content-Length（除非流式响应） - 若你用
c.Response().Write()手动输出，务必让CompressHandler自动处理长度，而不是自己算 - 验证方式：用
curl -I -H "Accept-Encoding: gzip" http://localhost:3000/xxx查看是否含Content-Encoding: gzip
真正容易被忽略的是 header 设置时机与中间件顺序 —— Buffalo 的中间件链是线性执行的，一旦 response 已经开始写入（比如日志中间件调用了 rw.WriteHeader()），后续中间件再设 header 就无效了。所以安全头必须放在最外层，而业务相关 header 最好在 handler 内部控制。
