必须用 fiber.New() 初始化应用并按需添加中间件，禁用 fiber.Default()；参数来源须严格区分：c.Params读路由占位符、c.QueryParam读查询字符串、c.FormValue读表单值；分层应为handler→service→repository→model单向依赖，依赖通过构造函数注入。
fiber.New() 启动，别碰 fiber.Default()；目录结构按 handler→service→repository→model 单向依赖建，别套 Spring 风的 controller/service/dao；路由参数、查询参数、表单值必须分清来源，混用必空。
为什么上线前必须换掉 fiber.Default()
它默认挂了 Logger、Recover、RequestID 三个中间件，开发时省事，上线就成性能和安全瓶颈：
- 每条请求都记完整日志（含
Authorization、Cookie等敏感头），I/O 压垮 QPS - TTFB 实测增加 0.3–0.8ms，在高并发下不可忽略
-
Recover中 panic 日志可能泄露堆栈或路径信息
正确做法是：fiber.New() 初始化空应用，再按需加中间件。比如只在 error 场景记日志，或对接 zerolog / zap 结构化日志系统。
c.Params、c.QueryParam、c.FormValue 到底读哪来的值
三者来源完全不同，且不能互相替代：
-
c.Params("id")只读路由占位符，如app.Get("/user/:id", ...)匹配/user/123后的"123" -
c.QueryParam("q")只读 URL query string，如/search?q=go中的"go" -
c.FormValue("name")是为application/x-www-form-urlencoded设计的；JSON 请求必须用c.BodyParser(&v)或c.Struct(&v)
常见错误：用 c.FormValue 解析 JSON body，结果永远为空；或把 id 放 query 里却用 c.Params 去取。
StrictRouting 导致 /users 和 /users/ 404 怎么办
Fiber 默认 StrictRouting: true，这是精确匹配，不是 bug。关掉它看似简单，但会引发更隐蔽问题：
- 若同时注册
/users和/users/:id，关掉 StrictRouting 后，/users/123可能被前者匹配，c.Params("id")拿不到值 - 前端、OpenAPI 文档、SDK 调用路径不一致，导致线上 404 频发
推荐方案是显式处理：
- 注册两条路由：
app.Get("/users", handler)和app.Get("/users/", redirectHandler) - 或加统一重定向中间件：
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) }
handler→service→repository→model 分层怎么写才不翻车
Go 的包机制决定了：循环导入、测试难、框架类型泄漏，90% 都是分层没守边界：
-
handler层只做三件事：解析参数、调用 service、写响应；不碰 DB、不写业务判断 -
service层接收已校验输入（如CreateUserReq），组合多个 repository，处理事务和规则；不暴露*fiber.Ctx -
repository层只封装数据访问，返回model.User或error；不碰 HTTP、不封装响应逻辑 -
model层是纯结构体 + tag，零方法、零依赖；绝不能出现func (u *User) Create(ctx *fiber.Ctx)
最容易被忽略的一点：所有依赖必须通过构造函数注入，比如 user_handler.go 里 new 一个 UserService，而不是全局变量 var db *gorm.DB —— 否则单元测试根本 mock 不了。
