buffalo框架不自动处理401响应，需手动在中间件或action中返回：中间件须显式设置www-authenticate头并调用c.render(401, ...)；c.error(401, ...)仅设状态码与错误体，不设认证头；框架坚持“显式优于隐式”，鉴权逻辑完全由开发者控制。
Buffalo 框架本身不自动处理 401，它把鉴权逻辑完全交给你控制——你得自己写中间件或在 action 里判断并返回 401，而不是指望框架兜底。
Buffalo 中间件里怎么手动返回 401
Buffalo 的中间件是拦截请求的第一道关卡，适合做统一鉴权。但注意：它不会自动加 WWW-Authenticate 头，这个头得你显式写。
- 用
buffalo.MiddlewareFunc包一层函数，在里面检查 token 或 session 是否有效 - 无效时别直接
c.Error(401, err)—— 这只设状态码，不设响应头，某些客户端（比如浏览器 Basic Auth 流程）会卡住 - 必须手动设置
c.Response().Header().Set("WWW-Authenticate", 'Bearer realm="api"') - 再调用
c.Render(401, r.JSON(map[string]string{"error": "invalid or missing token"}))
示例片段：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
authMiddleware := buffalo.MiddlewareFunc(func(c buffalo.Context) error {
token := c.Request().Header.Get("Authorization")
if token == "" || !isValidToken(token) {
c.Response().Header().Set("WWW-Authenticate", `Bearer realm="api"`)
return c.Render(401, r.JSON(map[string]string{"error": "invalid or missing token"}))
}
return nil
})
action 里 return c.Error(401, ...) 的实际效果
c.Error(401, ...) 是 Buffalo 提供的快捷方式，但它只做三件事：设状态码、写错误消息、设 Content-Type。它不设 WWW-Authenticate 头，也不触发浏览器的认证弹窗。
- 适合内部 API 场景，前端自己处理登录跳转或 token 刷新
- 不适合需要浏览器自动弹出 Basic Auth 对话框的场景
- 如果用了
renderers.JSON，错误体默认是{"error": "message"}，但字段名不能改——除非你重写整个 renderer - 注意：一旦调用
c.Error，后续中间件和 action 不再执行，所以它适合“终局拒绝”，不适合“先记录再放行”
为什么 Buffalo 不像 Express 或 Gin 那样内置 auth 中间件
Buffalo 的设计哲学是“显式优于隐式”。它不预装 JWT、OAuth2 或 session 鉴权模块，所有鉴权逻辑都由开发者选择并组装。
- 你得自己选库：
golang.org/x/oauth2、github.com/gofrs/uuid（配 session）、github.com/dgrijalva/jwt-go（已归档，建议换github.com/golang-jwt/jwt/v5） - session 存哪？Buffalo 默认用内存，但生产必须换
redis或postgres，否则多实例下 401 会乱跳 - token 过期检查要自己写，Buffalo 不管
exp字段校验，也不自动刷新
真正容易被忽略的是：WWW-Authenticate 头不是可选项——它是 HTTP 协议对 401 的强制要求。没它，严格来说响应就不合规，某些 HTTP 客户端（比如 curl -v）会警告，Postman 可能不触发自动重试逻辑。别省那两行代码。
