应严格遵循restful规范：用get/post/put/delete对应资源操作，资源名用复数如/users；路径参数用c.params()；状态码用fiber.statuscreated等常量；路由按资源分组注册；业务逻辑移至service层。
用 GET、POST、PUT、DELETE 对应资源操作，别写 /createUser 这类动词路由
Fiber 本身不强制 RESTful，但你一旦用错动词，后续所有中间件（如日志、权限、监控）都得额外适配。比如 /createUser 和 /users 在网关层看到的都是 POST，但前者语义模糊，后者能直接被 OpenAPI 工具识别为“创建用户资源”。
- 正确姿势：资源用复数名词，
/users、/orders、/products - 嵌套只用于强依赖关系，比如
/users/{userId}/orders合理，但/users/{userId}/orders/{orderId}/items超过三级就该改用查询参数：/items?orderId=123&userId=456 - Fiber 的
app.Get("/users/:id", handler)中:id是路径参数，不是 query string，别混淆c.Params("id")和c.Query("id")
用 fiber.StatusCreated、fiber.StatusNoContent 等常量代替硬编码状态码
写 c.Status(201) 看似省事，但容易拼错、难维护，且 IDE 无法提示语义。Fiber 提供了完整 HTTP 状态码常量，它们和标准一致，也方便做统一错误拦截。
- 创建成功必须返回
201 Created，并带上Location头：c.Location("/users/" + strconv.Itoa(newUser.ID)).Status(fiber.StatusCreated).JSON(newUser) - 删除成功推荐
204 NoContent（无响应体），而不是200 OK+ 空 JSON，避免前端误解析 - 不要用
500挡所有错误；数据库找不到记录该是404 Not Found，参数校验失败是400 Bad Request
把路由注册和 handler 拆开，别全塞在 main.go 里
Fiber 的 app.Get 看起来简单，但项目一上规模，main.go 就会变成路由大杂烩，加个新接口要翻百行代码。实际项目中，路由应该按资源分组、集中注册。
- 建
router/user_router.go，导出SetupUserRoutes(app *fiber.App)函数 - 在
main.go里只调一次：router.SetupUserRoutes(app)，清晰又易测 - 如果用了中间件（如 JWT 鉴权），优先用
app.Group("/users", authMiddleware)而不是每个路由单独挂，避免漏配
别在 handler 里直接操作数据库，用 service 层隔离业务逻辑
新手常把 GORM 查询写进 Fiber handler，导致测试困难、事务难控制、错误处理重复。Fiber 是 HTTP 层，它只该做协议转换和轻量校验。
- handler 只负责：解析参数、调用 service、序列化响应、设置状态码
- service 层封装完整业务流，比如
CreateUser()要包含密码哈希、发邮箱验证、写入关联地址等，这些都不该暴露给 HTTP 层 - 这样写单元测试时，可以直接 mock service，不用启 Fiber server 或连真实 DB
