Fiber 框架不内置 Controller 分层，因其设计哲学是极简与性能优先，仅提供 fiber.Ctx 和 func(fiber.Ctx) error 签名，不支持自动绑定、反射解析或依赖注入；所谓 Controller 是开发者通过结构体封装、方法转 handler、显式路由注册手动实现的业务分层。
Go 语言里 Fiber 框架本身不内置 Controller 分层概念——它没提供 Controller 类型、路由自动绑定或依赖注入容器。所谓“Controller 分层”，是你自己按业务语义组织 handler 函数和结构体，不是框架强制约定，更不是开箱即用的功能。
为什么 Fiber 没有原生 Controller 支持
Fiber 的设计哲学是极简与性能优先：它只暴露 *fiber.Ctx 和函数签名 func(*fiber.Ctx) error，所有逻辑都靠手动组合。不像 Gin 或 Beego 那样封装了 BaseController 或 c.Param("id") 自动绑定到 struct 字段。Fiber 不做反射解析、不缓存路由映射、不维护 handler 实例生命周期——这些正是它比同类快 2–3 倍的关键。
所以你看到的“Controller 教程”，本质是开发者用 Go 原生能力模拟分层：比如定义一个 UserController 结构体，把 Create、Update 方法写成接收 *fiber.Ctx 的函数，再注册到路由上。框架完全不管这个结构体是否存在。
如何手动实现可维护的 Controller 分层
核心就三点：结构体封装 + 方法转 handler + 路由显式注册。不依赖任何第三方包，纯标准库写法。
立即学习“go语言免费学习笔记（深入）”；
- 定义结构体时，把共享依赖（如 DB、Cache）作为字段注入，避免全局变量：
type UserController struct { db *sql.DB cache *redis.Client } - 每个方法签名必须匹配 Fiber handler：
func (c *UserController) Create(ctx *fiber.Ctx) error { var req CreateUserReq if err := ctx.BodyParser(&req); err != nil { return ctx.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid json"}) } // ... use c.db, c.cache return ctx.JSON(fiber.Map{"id": 123}) } - 注册路由时，用闭包或方法值绑定实例：
userCtrl := &UserController{db: db, cache: cache} app.Post("/users", userCtrl.Create) app.Get("/users/:id", userCtrl.Get) - 别用
new(UserController).Create这种每次 new 的写法——Fiber 复用*fiber.Ctx，但你不该让 Controller 实例也反复分配；复用结构体实例更安全
容易踩的坑：Context 生命周期和中间件顺序
Fiber 的 *fiber.Ctx 是复用对象，它的底层内存缓冲区在请求结束后会被重置。这意味着：
- 你在 Controller 方法里不能保存
ctx的引用（比如塞进 goroutine 或 map），否则下个请求会读到脏数据 - 中间件执行顺序直接影响 Controller 能否拿到正确数据：比如鉴权中间件必须在 Controller 前运行，并把用户 ID 写进
ctx.Locals("user_id")，Controller 才能取：func (c *UserController) Get(ctx *fiber.Ctx) error { userID := ctx.Locals("user_id").(int) // 注意类型断言 // ... } - 别在 Controller 方法开头就调
ctx.Next()——这不会“进入下一个 handler”，而是交还控制权；如果前面中间件已写响应（如 401），后续 Controller 根本不会执行 - 参数解析别混用：
ctx.Params("id")只读路径占位符（/user/:id），ctx.QueryParam("page")只读 URL 查询参数（?page=1），ctx.BodyParser()才解析 JSON body；用错位置会导致空值
真正难的不是写 Controller 结构体，而是守住 Context 的边界：它只活在一个请求周期内，不跨协程、不跨 handler、不跨中间件。所有“分层”设计，最终都要回归到这一条——否则性能优势和内存复用就全白费了。
