Fiber不提供RESTful路由自动模式，需手动声明路径与方法并严格遵循资源复数、路径参数命名及HTTP方法语义；路径参数始终为字符串，每次使用前必须显式类型转换与错误校验，否则易panic。
Fiber本身不提供RESTful路由“自动模式”，所有路径和方法绑定都需手动声明；你写对 app.Get("/todos") 和 app.Post("/todos")，它就按REST语义跑，写错就不是——关键在你是否严格遵循资源复数、路径参数命名、HTTP方法语义这三点。
路径必须用复数名词 + :id 动态段
资源路径不是靠框架识别，而是靠你写得一致。比如用户资源统一用 /users，别一会儿 /user 一会儿 /users，否则 OpenAPI 生成、前端 SDK、网关路由规则都会出问题。
-
/users✅ 列表获取（GET）、创建（POST） -
/users/:id✅ 单条获取（GET）、全量更新（PUT）、删除（DELETE） -
/users/:id/profile✅ 嵌套资源（需明确业务必要性，避免过度嵌套） -
/getUserById❌ 这是 RPC 风格，破坏幂等性与缓存语义 -
/users/:id/update❌ PUT 本就表示“更新”，加动词后缀冗余且导致重试风险
注意：:id 是占位符名称，不是字面量；Fiber 不校验它是否真为数字或 UUID，全靠你后续转换和校验。
c.Params("id") 返回字符串，不转类型直接用会 panic
路径参数永远是字符串，c.Params("id") 拿到的是原始输入，比如请求 /users/abc，c.Params("id") 就是 "abc"，不是 0 或错误。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 数字 ID：必须用
strconv.ParseInt(c.Params("id"), 10, 64)，并检查err != nil，失败应返回c.Status(fiber.StatusBadRequest).Send("invalid id") - UUID：用
uuid.Parse(c.Params("id"))，别用正则粗筛，它不校验版本和格式 - 禁止直接拼 SQL：
db.QueryRow("SELECT * FROM users WHERE id = '" + id + "'")—— 这是 SQL 注入温床 - 若想提前过滤非法路径，可注册带正则的路由：
app.Get("/users/:id/[0-9]+", handler)，但注意它不替代业务层校验
查询参数、表单、JSON 请求体要用不同方法取
混淆参数来源是高频崩溃点。Fiber 不自动区分，你得按协议位置选对 API：
- 路径参数（如
/users/:id）→ 用c.Params("id")，仅限路由中显式声明的段 - 查询参数（如
/users?page=2&limit=10）→ 用c.Query("page")或c.QueryInt("limit", 10)，未传时返回空或默认值 - 表单字段（
application/x-www-form-urlencoded）→ 用c.FormValue("email") - JSON 请求体 → 用
c.BodyParser(&v)，但注意它只做反序列化，不校验字段非空或格式
例如定义结构体：type User struct { Name string `json:"name"` }，客户端 POST {"name":""}，BodyParser 仍成功，Name 为空字符串——业务上这往往非法，必须手动检查：if u.Name == "" { c.Status(400).Send("name required") }。
别用 app.All 做兜底，404 处理要放最后
app.All("/api/*", handler) 看似方便，实则危险：它贪婪匹配所有子路径，且因 Fiber 路由匹配是顺序优先，一旦它注册在前，后面所有 app.Get("/api/users/:id") 都永远不会执行。
- 正确做法：把所有具体路由注册完，再用
app.Use(func(c *fiber.Ctx) { if c.Path() != "/" && !strings.HasPrefix(c.Path(), "/api/") { c.Status(404).Send("not found") } else { c.Next() } }) - 更推荐：用中间件链控制流程，
app.Use(jwtMiddleware)+app.Use(loggingMiddleware)，每个中间件调c.Next()，最终未匹配路由自然 404 - 切忌在中间件里直接
return c.Next()而不处理后续错误，JWT 失败后仍进业务 handler，会导致权限绕过
最易被忽略的是：路径参数类型安全不是“有就行”，而是“每次用前都必须校验”；哪怕你用了正则路由，c.Params("id") 仍是字符串，业务逻辑里漏掉 ParseInt 或没判 err，上线后第一个非数字 ID 就 panic。
