delete路由必须用app.delete而非app.get或app.post，因fiber中app.delete是独立方法，语义和中间件行为与模拟方式不一致；需用c.params("id")取路径参数，返回204状态码，且注意路由匹配顺序避免泛匹配拦截。
DELETE 路由注册必须用 app.Delete，不是 app.Get 或 app.Post
很多人写完 DELETE 接口却收不到请求，第一反应是前端没发对，其实常是后端路由注册错了。Fiber 的 app.Delete 是独立方法，不支持用 app.Method 模拟（比如 app.Method("DELETE", ...) 虽然能注册，但中间件行为和语义不一致，不推荐）。正确写法就是直呼其名：
app.Delete("/users/:id", func(c *fiber.Ctx) error {
id := c.Params("id")
// 删除逻辑
return c.SendStatus(fiber.StatusNoContent)
})
- 路径参数用
c.Params("id")获取，不是c.Query或c.Body - 返回
fiber.StatusNoContent（204）比200更符合 REST 语义，且避免客户端解析空响应体出错 - 别忘了加
return—— Fiber 中间件链靠显式return终止，漏写会导致后续中间件或默认 404 响应
DELETE 请求体（body）在标准 HTTP 中不被定义，Fiber 默认不解析
如果你试图在 DELETE 处理函数里调用 c.Body() 或 c.JSON() 解析 JSON body，大概率拿到空值。HTTP/1.1 规范未禁止 DELETE 带 body，但大多数客户端（如 fetch、axios 默认配置）、反向代理（Nginx 默认）、甚至某些浏览器 DevTools 都会忽略或截断它。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 真正需要传结构化数据时，改用
POST /users/:id/delete或PUT /users/:id/status更可靠 - 如果坚持用 body，需手动启用：在
fiber.New()时加配置fiber.Config{DisablePreParseMultipartForm: true}并自行读取c.Context().RequestBody()，但兼容性风险高 - 更稳妥的替代方案：把必要字段塞进 URL 查询参数（
c.Query("force") == "true"）或 Header（c.Get("X-Confirm-Delete")）
DELETE 路由匹配顺序影响实际执行，注意通配符冲突
Fiber 按注册顺序匹配路由，而 app.Delete("*") 或 app.Delete("/:path*") 这类泛匹配会吃掉所有 DELETE 请求，包括你本意想给 /api/v1/users/:id 的。
- 把具体路由（如
/users/:id）写在泛匹配（如/*）之前 - 避免在 DELETE 路由中混用
:id和*all——/users/:id/*会让c.Params("id")取到123/extra/path，而不是纯 ID - 调试时加个兜底日志：
app.Delete("*", func(c *fiber.Ctx) { log.Printf("unmatched DELETE: %s", c.Path()) })
测试 DELETE 接口时，curl 和 Postman 的 -X DELETE 默认不发 body
用 curl -X DELETE http://localhost:3000/users/123 是最简验证方式，但一旦加了 -d '{"force":true}'，就进入上面说的 body 兼容性雷区。
- Postman 中选 DELETE 方法后，Body 标签页默认置灰 —— 点开仍可填，但服务端很可能收不到
- 真要测带 body 的 DELETE，请用 Go 自写 client，或 Node.js 的
fetch显式设置method: 'DELETE', body: JSON.stringify(...) - 优先验证无 body 场景是否走通，再考虑是否真有必要让 DELETE 携带 payload
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
