restful接口设计核心是资源导向：用复数名词路径（如/todos）、http方法表达操作（get/post/put/delete）、正确状态码（200/201/204/404），禁用动词路径（如/gettodobyid），并严格校验请求体与参数。
fiber 本身不强制 REST 风格，但它的路由设计和响应控制能力足够支撑标准 RESTful 接口——关键不是“能不能”，而是你是否显式遵循 HTTP 方法语义、资源路径约定和状态码规范。
定义资源路径时必须用复数名词 + /:id 动态参数
REST 的核心是资源导向，fiber 路由写法本身不限制风格，但若想真正符合 REST，路径必须体现资源层级，而不是动作。比如：
-
/todos（GET 列表 / POST 创建）✅ -
/todos/:id（GET 单个 / PUT 全量更新 / DELETE 删除）✅ -
/getTodoById或/deleteTodo❌ —— 这是 RPC 风格，破坏了统一接口原则
注意：c.Params("id") 返回的是字符串，实际使用前需转成整型或校验格式，否则可能 panic 或逻辑错位。
c.BodyParser() 默认不校验字段，必须手动加空值/类型检查
Flask 有 request.get_json() + 手动判断，fiber 的 c.BodyParser(&v) 更简洁，但它只做结构映射，不拦截空字段、零值或非法类型。比如：
type Todo struct {
ID int `json:"id"`
Title string `json:"title"`
}
当客户端 POST {"title":""}，BodyParser 仍会成功，Title 被赋为空字符串，而业务上这可能是非法输入。
- 务必在解析后检查关键字段：如
if todo.Title == "" { c.Status(400).Send("title required") } - 更稳妥的做法是引入
go-playground/validator并配合 struct tag：json:"title" validate:"required,min=1" - 不要依赖
BodyParser的 error 判断是否数据合法 —— 它只管反序列化是否崩溃
状态码不能只靠 c.Status()，要匹配 HTTP 方法语义
很多新手写 c.Status(200).JSON(...) 贯穿所有响应，这会导致前端难以区分“获取成功”和“创建成功”。fiber 提供了快捷常量，但得用对：
- GET
/todos→c.Status(fiber.StatusOK).JSON(todos)（200） - POST
/todos→c.Status(fiber.StatusCreated).JSON(todo)（201） - DELETE
/todos/:id→c.SendStatus(fiber.StatusNoContent)（204），不是 200 - 未找到资源 →
c.Status(fiber.StatusNotFound).Send("not found")（404）
漏掉 StatusNoContent 或误用 SendString 替代 SendStatus，会让前端收到 200 却没有 body，造成解析异常。
中间件里别直接 return c.Next()，要处理 c.Next() 后的错误
比如日志中间件或 JWT 验证，常见写法是：
app.Use(func(c *fiber.Ctx) error {
// ... 验证逻辑
if !valid {
return c.Status(401).Send("unauthorized")
}
return c.Next() // ✅ 正确：把控制权交还链路
})
但问题在于：如果后续 handler panic 或返回 error，c.Next() 的返回值没被接住，整个请求就静默失败。生产环境必须包裹：
- 用
app.Use(func(c *fiber.Ctx) error { ... })做前置校验没问题 - 但全局错误捕获要用
app.Use(func(c *fiber.Ctx) error { ... })放在最后，检查c.Response().StatusCode()或监听c.Context().Done() - 更推荐方式：注册
app.Use(func(c *fiber.Ctx) error { defer func() { if r := recover(); r != nil { c.Status(500).Send("server error") } }(); return c.Next() })
否则一个未捕获的 panic 就会让整个请求卡死或返回空响应，而日志里还没痕迹。
