Fiber原生支持PUT/DELETE，无需HiddenHttpMethodFilter；因HTML表单仅支持GET/POST，故需JS（如fetch）发送真PUT/DELETE请求。
Fiber 默认不拦截或重写请求方法，PUT/DELETE 直接走原生 HTTP 方法，无需 HiddenHttpMethodFilter 那套模拟逻辑。它不像 Spring Boot 那样默认禁用非标准方法或依赖表单隐藏字段——只要你前端发的是真 PUT 或 DELETE，Fiber 就能原样收到并路由。
为什么浏览器表单发不出真正的 PUT/DELETE？
HTML <form> 的 method 属性只认 get 和 post，写 method="put" 会被浏览器忽略，退化成 GET。这不是 Fiber 的问题，是 HTML 规范限制。
- 真正发出
PUT/DELETE必须用 JavaScript（fetch、axios等） - 后端 Fiber 不做方法转换，所以也不需要配置
_method隐藏字段或等效开关 - 如果你在调试时发现路由没匹配上，先检查浏览器 Network 面板里请求的
Request Method到底是不是PUT，而不是看代码里写的method="put"
Fiber 中注册 PUT/DELETE 路由的写法
直接用 app.Put() 和 app.Delete()，参数和 Get/Post 一致，无额外约束。
- 路径支持占位符：
app.Put("/user/:id", handler) - 可绑定查询参数、请求体、Header：
c.Params().Get("id")、c.Body()、c.Get("Authorization") - 注意：PUT 请求体默认是 raw data（如 JSON），不是
application/x-www-form-urlencoded；若前端用FormData发送，需手动解析 multipart，Fiber 不自动处理
示例：
app.Put("/api/user/:id", func(c *fiber.Ctx) error {
id := c.Params("id")
var user User
if err := c.BodyParser(&user); err != nil {
return c.Status(400).SendString("invalid JSON")
}
// 更新逻辑...
return c.JSON(map[string]string{"status": "updated", "id": id})
})
常见 404 或 405 错误怎么排查？
这两个状态码最常出现在 PUT/DELETE 场景，原因很具体：
-
404：路由路径或方法完全没注册，比如写了app.Put("/user", ...)，但请求是PUT /users（少了个 s） -
405 Method Not Allowed：路径存在，但注册的方法不匹配，比如只注册了app.Post("/user", ...)，却用PUT访问 - Fiber 默认不开启 OPTIONS 预检，如果前端跨域发
PUT，且带自定义 Header（如Authorization），浏览器会先发OPTIONS请求——此时若没配 CORS 中间件，就会卡在预检失败，表现为网络面板里只有OPTIONS且状态 404/405
解决办法：加 fiber.New(fiber.Config{StrictRouting: true}) 强制路径严格匹配，并确保 app.Use(cors.New()) 开启（尤其开发期）。
真正容易被忽略的是：Fiber 的路由注册顺序无关紧要，但它对路径末尾斜杠敏感（/user 和 /user/ 是两个路由），而很多前端框架（如 Vue Router）或代理（如 Nginx）会自动补斜杠——这会导致看似一样的 URL 实际触发不同路由。
