Go语言怎么做CRUD生成器_Go语言CRUD代码生成教程【最新】

sqlc 是当前最稳的 Go CRUD 代码生成方案，它将 SQL 编译为强类型 Go 函数，零反射、IDE 可跳转、字段改名即报错，专注 SQL 即契约，无需手写模板或使用 ORM。

用 sqlc 生成 Go CRUD，比手写快且类型安全

先说结论：别再费劲自己写模板生成器了。sqlc 是目前 Go 生态里最稳健的 CRUD 代码生成方案。它的思路很清晰——不生成一套新的 ORM，而是直接将你写好的 SQL 查询，编译成强类型的 Go 函数。这意味着零运行时反射、没有魔法字符串、IDE 可以完美跳转，一旦数据库字段改名，编译立刻就会报错。

一个常见的误区是，试图用 genny 或 text/template 手搓一个生成器。结果往往是维护成本飙升，SQL 语句和 Go 类型定义脱节，遇到复杂的 JOIN 查询时，结构体嵌套更是让人头疼。sqlc 则让你回归本质：专注写好 SQL。你只需要写下 SELECT id, name FROM users，它就能帮你生成对应的 func (q *Queries) GetUsers(ctx context.Context) ([]User, error)。

当然，使用前有几个关键点必须注意：

• 它主要支持 PostgreSQL 和 MySQL（SQLite 支持有限），并且要求数据库表有明确的主键和非空约束。否则，生成的 struct 字段可能会是指针类型，徒增 nil 判断的负担。
• 配置文件 sqlc.yaml 里，务必打开 emit_json_tags: true 这个选项。否则生成的 struct 无法被 json.Marshal 正常序列化。
• 查询文件后缀必须是 .sql，每个 SQL 语句前需要加上格式化的注释，例如 -- name: GetUsers :one。冒号后的 :one、:many 或 :exec 指明了返回类型，一旦写错，代码生成就会失败。

怎么让 sqlc 支持软删除和时间戳自动填充

原生的 sqlc 本身不处理业务逻辑，但这不代表我们无法实现软删除或自动管理时间字段。秘诀在于，将逻辑约束上移到 SQL 层进行约定，从而避免在 Go 代码里反复书写 CreatedAt: time.Now() 这类样板代码。

举个例子，定义用户表时，可以加上 deleted_at TIMESTAMPTZ DEFAULT NULL 字段。然后，在所有查询语句中统一附加条件 WHERE deleted_at IS NULL。对于插入和更新操作，则显式地写上 created_at = NOW(), updated_at = NOW()。这样一来，sqlc 生成的 Go 函数天然就包含了这些过滤和填充逻辑，无需再编写额外的包装层。

立即学习“go语言免费学习笔记（深入）”；

• 切忌在 Go 业务层做 if u.DeletedAt != nil 这样的过滤判断。这会导致同一张表的查询逻辑分散在各处，也违背了 sqlc 所倡导的“SQL 即契约”的设计哲学。
• 更新操作应统一使用类似 UPDATE users SET name = $2, updated_at = NOW() WHERE id = $1 的语句，确保 updated_at 字段永远由数据库驱动更新。
• 如果确实需要物理删除，建议单独编写一个如 -- name: HardDeleteUser :exec 的查询，与常规业务查询隔离，从根本上避免误用。

sqlc 生成的代码怎么接入 Gin/Gin-Zap 日志链路

sqlc 生成的 Queries 结构体本身是纯净的，不包含上下文透传或日志记录能力。如果直接把一个裸的 *sql.DB 连接丢给业务 Handler，会带来问题：请求的 Trace ID 无法传递，日志缺乏上下文，出错了也难以定位到具体的 SQL 语句。

正确的做法是在调用生成函数之前，于外层进行封装。比如，通过 ctx = logger.WithContext(ctx, zap.String(“sql_op”, “GetUsers”)) 将操作标识注入上下文，然后再将这个 ctx 传递给 q.GetUsers(ctx)。这里有个细节需要注意：sqlc 生成的所有函数，第一个参数都是 context.Context，调用时千万别漏传。

• 避免使用全局的 log.Printf 来打印 SQL 参数。这既不安全（可能泄露敏感数据），也无法将日志与特定的请求生命周期关联起来。
• 如果项目使用了 pgxpool，记得在 sqlc 配置中设置 engine: “postgresql” 并且打开 emit_db_sql: true。否则，生成的函数可能无法正确接收 pgx.Tx 类型的事务对象。
• 对于慢查询监控，可以在函数调用前后计算耗时，并通过 zap.Duration(“sql_duration”, time.Since(start)) 记录。这个逻辑应该放在外层 defer 中执行，而不是试图修改生成的代码内部。

为什么不用 ent 或 gorm 自动生成 CRUD

首先要明确，ent 和 gorm 本质上是运行时 ORM，而非纯粹的代码生成器。ent 的 ent generate 命令虽然也生成代码，但其产出物是一套 Builder 模式的接口，最终执行时仍然依赖于动态构建 SQL。gorm 则更甚，全程依赖反射和字符串拼接，字段名拼写错误只能在运行时暴露，IDE 无法提供跳转支持，单元测试的 Mock 也相当困难。

sqlc 的核心优势在于其「SQL 优先」的哲学。它建立了一个高效的反馈闭环：数据库 DDL 变更 → 修改对应的 SQL 文件 → 执行 sqlc generate → Go 代码编译失败 → 开发者立刻知道哪些调用点需要同步调整。这种确定性和即时反馈，是传统 ORM 难以提供的。

另一个容易被低估的优势是迁移成本。对于已有项目，引入 sqlc 通常只需要补全 SQL 查询文件，几乎无需改动现有的数据库结构和 DAO 层调用方式——仅仅是将原来手写的 rows.Scan()