Fiber不自动实现RESTful，需手动遵循资源导向规范：用复数路径如/todos和/todos/:id，禁用动词路径；c.Params("id")返回字符串须显式转换并校验；状态码须匹配HTTP语义（如201创建、204删除、404未找到、422校验失败）。
能写，但 Fiber 不自动帮你 RESTful —— 它只管路由和响应，REST 是你手动对齐的约定。
怎么定义 /todos 和 /todos/:id 这类标准路径
Fiber 的 app.Get、app.Post 等方法本身不校验是否 RESTful，路径写法全靠你主动约束：
- 资源路径必须用复数名词：
/todos✅，别混用/todo❌ - 单条操作统一走
/:id动态段：app.Get("/todos/:id", handler)，不是/todo?id=123 - 不要在路径里塞动词：
/deleteTodo或/getById是 RPC 风格，破坏资源抽象 - 如果要用子资源（如
/todos/:id/comments），建议用app.Group()分组管理，避免中间件污染
c.Params("id") 返回 string，别直接当 int 用
这是最常 panic 的地方。Fiber 不做隐式类型转换，c.Params("id") 永远是字符串：
- 必须手动转：用
strconv.Atoi(c.Params("id"))或strconv.ParseUint(..., 10, 64) - 必须检查 error：若传入
/todos/abc，不检查就 panic - ID 是 UUID？别用正则粗筛，用
uuid.Parse(c.Params("id")) - 数据库查询前务必校验转换结果，否则可能查空或触发 SQL 注入（尤其拼 raw query 时）
c.BodyParser(&v) 不等于数据校验
c.BodyParser() 只负责 JSON 反序列化，不拦空字段、零值或业务非法输入：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 结构体字段要大写 +
json:"title"tag，漏了就解码失败或赋零值 - 客户端 POST
{"title":""}，c.BodyParser()仍成功，Title是空字符串 - 关键字段得手动检查：
if todo.Title == "" { c.Status(400).Send("title required") } - 更稳的做法是加
validate:"required,min=1"tag，再用go-playground/validator验证
状态码不能全用 200，得匹配 HTTP 方法语义
前端靠状态码做逻辑分支，乱用会导致 fetch 不进 catch、缓存策略错乱、重试失效：
- GET 列表 →
c.Status(fiber.StatusOK).JSON(todos)（200） - POST 创建 →
c.Status(fiber.StatusCreated).JSON(todo)（201），最好加c.Location("/todos/" + id) - DELETE 成功 →
c.SendStatus(fiber.StatusNoContent)（204），不是SendString("")（会返回 200） - 资源不存在 →
c.Status(fiber.StatusNotFound).Send("not found")（404） - 业务校验失败（如邮箱格式错）→ 优先用
fiber.StatusUnprocessableEntity（422），比 400 更明确
最容易被忽略的是：路径参数类型转换和状态码语义绑定，这两处一错，轻则接口不可靠，重则服务崩溃或前端行为异常。Fiber 给你足够自由，但也要求你对 HTTP 协议和 Go 类型系统有显式认知。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
