Fiber 通过 HTTP 动词映射（Get/Post/Put/Patch/Delete）天然支持 REST，路径应表资源而非动词，JSON 需手动解析与返回并显式设状态码，ID 参数须显式转换并校验错误，中间件需避免覆盖响应且错误响应要结构一致。
直接用 fiber.New() 初始化应用，配好路由和处理函数，就能跑出符合 REST 规范的 API。它不强制你写什么样板，但默认行为天然贴合 REST 原则——比如动词对应 HTTP 方法、路径表达资源、状态码由你显式控制。
如何定义标准 CRUD 路由
Fiber 的路由方法名（Get、Post、Patch、Delete）和 HTTP 动词一一对应，这是 REST 的基础。别用 app.All() 或混用动词去模拟操作，那会破坏语义。
-
/users→app.Get("/users", ...)查列表，app.Post("/users", ...)创建新用户 -
/users/:id→app.Get("/users/:id", ...)查单个，app.Put("/users/:id", ...)全量更新，app.Patch("/users/:id", ...)局部更新，app.Delete("/users/:id", ...)删除 - 路径里不要出现动词，比如
/users/getById或/deleteUser是反模式
如何正确解析和返回 JSON 数据
Fiber 默认不自动解析请求体，也不强制返回 JSON；你得自己调用 c.BodyParser() 和 c.JSON()，这反而让你对数据流有完全控制权。
- 接收 JSON：用
c.BodyParser(&v)，失败时检查返回的error，别忽略它 - 返回 JSON：用
c.Status(201).JSON(v)显式设状态码，c.JSON()默认是 200，创建资源必须用 201 - 空响应（如 DELETE 成功）用
c.SendStatus(204)，不是c.JSON(nil)或空字符串 - 错误响应统一用
c.Status(xxx).JSON(fiber.Map{...})，避免混合字符串和结构体
为什么 c.Params("id") 返回的是字符串，而数据库 ID 往往是 int
因为 URL 路径参数永远是字符串，Fiber 不做隐式类型转换——这是好事。你得自己转，且必须处理转换失败的情况。
- 别直接
strconv.Atoi(c.Params("id"))，要检查 error - 更安全的做法是封装一个辅助函数，比如
parseID(c *fiber.Ctx) (int, error)，在所有带 ID 的路由里复用 - 如果 ID 是 UUID，用
uuid.Parse(c.Params("id"))，同样不能跳过 error 检查 - 数据库层（如 GORM）通常接受
uint或int64，别把字符串直接塞进去，否则可能静默失败或类型错位
中间件里容易忽略的 REST 一致性细节
身份验证、日志、CORS 这些中间件本身不破坏 REST，但写法不对就会悄悄污染语义。
-
c.Next()后别再改状态码或响应体，否则上层 handler 的c.Status(404).JSON(...)可能被覆盖 - 鉴权中间件拒绝请求时，用
c.Status(401).JSON(...)或403，别用400或重定向 - CORS 中间件要设
AllowOrigins和AllowMethods，尤其AllowMethods必须包含PUT、PATCH、DELETE，否则前端发不出这些请求 - 日志中间件记录时，把
c.Response().StatusCode()记下来，这是判断是否真返回了 200/201/404 的唯一依据
最常被跳过的其实是错误响应的结构一致性：400 应该返回字段校验失败详情，404 要明确说 “resource not found”，500 则不该暴露堆栈。这些不是框架管的，是你在每个 handler 里手写的逻辑——REST 的约束力，最终落在每一行 c.Status() 和 c.JSON() 上。
