Buffalo默认支持PUT，但路由注册需用app.PUT("/users/:id", UserUpdate)格式，冒号前缀是约定；路径写{id}会404，因默认路由器不识别该语法。
Buffalo 默认支持 PUT，但路由注册方式容易写错
Buffalo 的 app.PUT() 方法本身是可用的，问题常出在路径写法上。很多人照搬 Gin 或 Echo 的风格，写成 app.PUT("/users/{id}", UserUpdate)，这会导致 404——因为 Buffalo 的默认路由器（http.ServeMux 衍生）不识别 {id} 这类占位符语法，它只做前缀匹配或字面量精确匹配。
正确写法是用标准路径格式，把参数当作普通路径段处理：
-
app.PUT("/users/:id", UserUpdate)—— 冒号前缀是 Buffalo 的约定，不是正则也不是通配符 - 别写
/users/{id}、/users/*或/users/（后者会匹配所有以该前缀开头的路径，比如/users/123/extra） - 如果需要更灵活的路径解析（比如多级嵌套或可选段），得换用
gorilla/mux并手动注入到app.Handler
PUT 请求体解析失败？检查中间件链是否干扰
Buffalo 默认启用 session.Middleware 和 csrf.Middleware，而这两个中间件在处理非 GET/POST 请求时可能静默失败或跳过 body 解析，导致 c.Request().Body 为空或 c.Param("id") 可取但 c.Request().FormValue() 拿不到数据。
解决办法是显式禁用无关中间件，尤其在纯 API 场景下：
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 删掉或注释掉
app.Use(session.Middleware())和app.Use(csrf.Middleware()) - 确认没调用
app.Use(plugins.Static())——静态文件中间件会提前 consume body - 用
c.Request().Body手动读取 JSON：先io.ReadAll(c.Request().Body)，再json.Unmarshal()，别依赖自动绑定（Buffalo 的自动绑定主要面向表单）
外网 PUT 返回 405？Nginx 或网关层在拦截方法
内网直连正常、外网报 405，大概率不是 Buffalo 的问题，而是请求没进到 Buffalo 就被拦下了。常见拦截点有：
- Nginx 默认只允许
GET、HEAD、POST，需显式添加PUT到limit_except块或if判断中 - 云厂商 WAF 或安全组策略里禁用了
PUT/PATCH/DELETE方法 - CDN 配置了“仅缓存 GET/HEAD”，对其他方法直接返回 405
- 检查响应头是否有
Allow: GET, POST，如果有，说明拦截发生在 Buffalo 之前
验证方式：在 Nginx 日志里加 $request_method 字段，看外网请求进来时 method 是否已被篡改或丢弃。
想用 Buffalo 做 BFF 或网关？别用 PUT 路由，换方案
Buffalo 的 PUT 路由机制适合 CRUD 类后端服务，但不适合 BFF 或网关场景。原因很实在：
- 它没有原生反向代理能力，你得自己写
httputil.NewSingleHostReverseProxy()，然后绕过 Buffalo 的中间件链，否则超时、重试、header 透传都难控制 -
app.PUT()注册的 handler 是同步执行的，无法做下游并发聚合；BFF 需要的是自由组合多个http.Client调用，而不是一个固定 endpoint 绑定一个 struct - 所有 Buffalo 中间件默认忽略 context 传递，
server.Shutdown()时长连接易卡住，PUT 请求若带大 body，优雅退出基本不可靠
真正需要 PUT 语义的聚合层，建议用 gin 或 net/http 自建，把 Buffalo 降级为只暴露 /api/v1/users/:id 这类原子接口的后端服务——这样既保住了开发效率，又避开了它在非 MVC 场景下的设计硬伤。
