Fiber项目无需CLI或模板，只需三步：初始化配置、注册路由、启动监听；最简main.go仅需四行代码，禁用启动日志、直接Listen，路由初期全写main.go，配置按需启用而非堆砌。
直接用 fiber.New() 初始化就行，不需要模板、CLI 或项目脚手架——Fiber 本身就没设计“项目创建流程”，所谓“创建方法”本质是初始化配置 + 路由注册 + 启动监听三步。
为什么不用 gofiber/cli 或第三方模板
Fiber 官方从 v2 起就不再维护 CLI 工具；社区里那些 “fiber-starter” “fiber-boilerplate” 多数停留在 v1，且硬塞了 GORM、JWT、Swagger 等非必需依赖，反而掩盖了 Fiber 最核心的轻量逻辑。你真正要做的，只是：
- 新建一个
main.go go mod init example.com/appgo get github.com/gofiber/fiber/v2- 写四行启动代码
没有 makefile、没有 cmd/ 目录、没有 config struct 嵌套三层——这就是 Fiber 的起点。
最简可用的 main.go 长什么样
别抄教程里带日志、中间件、错误处理的“完整版”。压测前或调试初期，只留最骨干的几行：
package main
import "github.com/gofiber/fiber/v2"
func main() {
app := fiber.New(fiber.Config{
DisableStartupMessage: true, // 关掉那行 "Server started" 日志
})
app.Get("/", func(c *fiber.Ctx) error {
return c.SendString("ok")
})
app.Listen(":3000")
}
注意两点：DisableStartupMessage: true 是上线前必加项；app.Listen() 不要包在 log.Fatal() 里——它本身已 panic-safe，加 log.Fatal 反而掩盖真实启动失败原因（比如端口被占）。
路由定义别过早分文件
新手常一上来就拆 routes/、handlers/、controllers/，结果每个小接口都要跨三个包 import。Fiber 的路由注册是纯函数式调用，app.Get() 和 app.Post() 就是普通 Go 函数，参数是 func(*fiber.Ctx) error。初期所有路由写在 main.go 里完全合理：
- 增删接口时 Ctrl+F 一眼扫完全部路径
- 避免循环 import（比如 handler 依赖 service，service 又要调用 c.Status()）
- 上线前用
go build -ldflags="-s -w"打包，二进制里没任何冗余符号
等接口超 20 个、团队协作明确分工后，再按功能域拆 userRoutes(app)、orderRoutes(app) 这类函数——不是按“层”，而是按“业务边界”。
别在 New() 里堆配置项
看到文档里列了一堆 Config 字段就全抄进去？大可不必。90% 场景只需关注三个：
-
DisableStartupMessage: true—— 静默启动 -
Immutable: false（默认值）—— 别设true，否则 ctx.Params() 返回的字符串每次都要新分配内存 -
Prefork: false（默认值）—— 单机压测发现 CPU 持续 ≥95% 且物理核 ≥6 再开，开了就得自己管子进程信号
像 ProxyHeader、StrictRouting、CaseSensitive 这些，除非你明确遇到反向代理转发异常或大小写路由冲突，否则保持默认即可。改一个配错一个，不如先跑通再调优。
真正容易被忽略的是：Fiber 的“项目结构”根本不是目录树，而是 ctx 生命周期管理意识——所有从 c.Params()、c.Query()、c.BodyBytes() 拿到的数据，都只在当前 handler 内有效；一旦离开函数作用域，再拿就是上一个请求的脏数据。这点比任何目录规范都关键。
