fiber框架不内置orm或代码生成器，仅专注http路由与中间件；数据库层需搭配sqlc等外部工具实现类型安全的crud，强调编译期检查与零运行时反射。
Fiber 框架本身不提供 ORM 或代码生成器，必须搭配外部工具或手写模板。它只负责 HTTP 路由和中间件，数据库层完全交由开发者选型（如 GORM、SQLX、Squirrel 或原生 database/sql）。所谓“自动生成基础操作代码”，本质是工程化提效手段，不是 Fiber 内置能力。
为什么不能直接用 fiber.New() 生成 CRUD 文件？
Fiber 是极简 Web 框架，设计哲学就是“零魔法”——它不侵入业务逻辑，也不解析结构体生成 SQL。不像 Beego 的 bee generate 或 Laravel 的 php artisan make:model，Fiber 没有 CLI 工具链，也没有模型定义到数据库迁移的绑定机制。
-
fiber.App实例只处理请求生命周期，不感知数据库表结构 - 没有内置的 struct tag 映射规则（比如
gorm:"column:name"是 GORM 的，不是 Fiber 的） - 即便你用
go:generate注释，也得靠第三方工具（如sqlc或ent）驱动，Fiber 不参与生成过程
推荐组合：SQLC + Fiber —— 类型安全、零运行时反射
这是目前 Go 生态中与 Fiber 配合最干净的方案：SQLC 编译时把 SQL 查询转成强类型 Go 函数，Fiber 只负责调用这些函数并返回 JSON。
- SQLC 根据
.sql文件和数据库 schema 生成Queries结构体和方法，例如q.CreateUser(ctx, arg) - Fiber 路由里直接注入生成的
*Queries，无需手动写db.QueryRow或拼接 SQL - 无运行时性能损耗（对比 GORM 的 reflect.Value 调用），适合高 QPS 场景
- 错误在编译期暴露：字段名改了、类型不匹配，
go build直接失败
示例片段：
func setupRoutes(app *fiber.App, q *db.Queries) {
app.Post("/users", func(c *fiber.Ctx) error {
var req CreateUserRequest
if err := c.BodyParser(&req); err != nil {
return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": err.Error()})
}
user, err := q.CreateUser(c.Context(), db.CreateUserParams{
Name: req.Name,
Email: req.Email,
})
if err != nil {
return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
}
return c.Status(fiber.StatusCreated).JSON(user)
})
}
常见踩坑点：生成代码后忘记注入依赖或上下文传递
很多人跑通 SQLC 生成，却在 Fiber handler 里卡在数据库连接或 context 传递上：
- 生成的
Queries方法第一个参数必须是context.Context，但c.Context()是*fiber.Ctx，需显式转换（c.Context().Context()）或封装适配层 - 别把
*sql.DB或*Queries声明为全局变量——并发下可能被意外覆盖；应通过app.Use(func(c *fiber.Ctx)注入，或用依赖注入容器（如 Wire） - SQLC 默认不生成事务辅助方法，需要自己用
db.BeginTx+defer tx.Rollback()包裹多个q.*()调用 - 如果用了 Docker 启动 MariaDB，SQLC 的
schema.sql必须包含CREATE TABLE完整定义，不能只靠pg_dump导出（MariaDB 兼容性需验证）
真正关键的不是“怎么生成”，而是“生成后如何让 Fiber 安全、可测、可维护地用起来”——这取决于你是否把数据库访问层和 HTTP 层彻底解耦，而不是指望框架替你做决定。
