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()
