如何在Golang微服务中部署Jet作为高性能SQL构建器

先得说清楚一个关键认知：Jet 不是那种可以“部署”的中间件或服务。它本质上是一个编译期的代码生成工具，外加一个类型安全的 SQL 构建库。你既不用启动 Jet 进程，也不需配置端口或搞什么服务注册——它不走网络，也不占运行时资源，直接集成进 Go 项目就能跑起来。 那怎么用呢？真正的组装流程，其实藏在几个容易被忽略的环节里。

jet CLI 安装后，必须在构建前执行一次生成命令

Jet 核心价值来自于 `./.gen/` 目录下那些类型安全的 Go 代码。这些代码必须在你动手写查询之前生成好，并随整个项目一起编译。一个很常见的坑是：只装了 `jet` 命令，但忘了跑生成步骤，结果 `import` 时报错说找不到包。 必须注意的是： - 安装方式是 `go install github.com/go-jet/jet/v2/cmd/jet@latest`，这是 CLI，不是库的 `go get`。 - 生成命令要带完整的 DSN 和 schema 名，例如：`jet -dsn=postgresql://user:pass@localhost:5432/mydb?sslmode=disable -schema=public -path=./.gen`。 - 生成路径建议固定为 `./.gen`，并且一定要加进 `.gitignore`。生成的文件千万别手动改。 - 如果数据库结构改了，重新跑一次 `jet` 命令就能刷新全部类型，业务代码完全不需要动。

SQL 构建器需要显式导入生成的 table/model 包

Jet 没有全局注册机制，也不提供自动发现。所有表、字段、枚举都来自生成的代码，必须显式 `import`。很多人容易在路径拼错或用旧包名上栽跟头。 来，看一个典型场景： - 假设生成路径是 `./.gen/mydb/public/table`，那导入语句就应该是 `import "./.gen/mydb/public/table"`。注意是相对路径，不是模块路径。 - 字段名默认是大驼峰（比如 `table.User.UserID`），但实际数据库列名可能是小写加下划线（`user_id`）。这个取决于生成时的配置，不要自己硬编码成字符串去匹配。 - 最要警惕的是：别把原始 SQL 字符串和 Jet 构建器混在一起用。比如 `WHERE(table.User.Name == "foo")` 是类型安全的，但 `WHERE("name = 'foo'")` 直接就绕过了检查，那 Jet 的防护意义就完全失效了。

执行查询必须自己管理 database/sql.Conn 或 *sql.DB

Jet 只负责生成 SQL 字符串和参数，它不封装连接池，也不管事务控制。它和 `database/sql` 是各司其职的关系，你需要自己传入 `*sql.DB` 或 `sql.Tx`。 非得加一句的是：构建完语句后调用 `stmt.Sql()`，你会拿到 `(string, []interface{})`，然后把它交给 `db.Query()` 或 `tx.Exec()`。到这一步之前，Jet 的工作就已经结束了。 如果涉及多表 JOIN 查询，并且有 NULL 值字段（比如外键未关联的情况），生成的结构字段类型会是 `sql.NullString` 之类的，不能直接赋值给普通 `string`，需要判空或用 `.Scan()` 处理。 而对于复杂嵌套结果（比如 1:N 关系），光靠一个 `SELECT` 是搞不定的。得手写两次查询，再手动关联。Jet 不做 ORM 式的懒加载，这一点必须心里有数。 最容易被忽略的一点：Jet 生成的代码依赖 `github.com/go-jet/jet/v2` 这个运行时库，但这个库本身完全不碰连接的生命周期。如果微服务里用了连接池（比如 `db.SetMaxOpenConns()`），Jet 对此一无所知。它的职责很清晰：生成正确的 SQL，剩下的全部交给你。