Golang中使用Sqlx简化数据库操作与语言学习中的代码封装-Golang-PHP中文网

应优先选用 Get；它自动处理 Scan 和 sql.ErrNoRows 错误，避免因漏判导致 panic，而 QueryRowx 需手动 Scan 且易忽略错误判断，仅在需复用 Row 或调用 ColumnTypes 等场景才适用。

golang中使用sqlx简化数据库操作与语言学习中的代码封装

Sqlx 的 `QueryRowx` 和 `Get` 到底该选哪个？

查单行数据时，QueryRowx 和 Get 表面行为相似，但底层处理逻辑不同：前者返回 *sqlx.Row，后者直接填充结构体并检查 sql.ErrNoRows。实际用 Get 更安全——它自动调用 Scan 并统一错误判断，避免漏掉 ErrNoRows 导致 panic。

常见错误是写成：err := db.QueryRowx("SELECT name FROM users WHERE id=$1", 1).Scan(&name)，但没检查 err == sql.ErrNoRows，结果一查不到就 panic。换成 err := db.Get(&user, "SELECT * FROM users WHERE id=$1", 1)，错误直接包含语义（比如查不到就是 sql.ErrNoRows），不用额外 if 判断。

Get 要求目标变量地址可寻址（不能传字面量或只读字段）
QueryRowx 更灵活，适合需要手动控制 Scan 时机或复用 Row 的场景（比如后续调用 ColumnTypes()）
PostgreSQL 下若字段名含大小写，确保 struct tag 用 db:"field_name" 显式映射，否则 Get 可能静默失败（字段不匹配就不赋值，也不报错）

Struct tag 里 `db` 和 `json` 能共用吗？

可以共用，但要注意优先级和覆盖风险。sqlx 默认读取 db tag，没定义时才 fallback 到 json tag。这意味着如果只写 json:"user_id"，sqlx 会尝试按 user_id 去匹配数据库列名——但多数数据库用下划线命名（user_id），而 Go 结构体习惯驼峰（UserID），所以必须显式写 db:"user_id"。

容易踩的坑是误以为加了 json tag 就够了，结果查询时字段全为零值，日志也无报错。sqlx 不会报“字段未映射”，而是跳过赋值。

推荐写法：UserID int `db:"user_id" json:"user_id"`
别依赖 fallback：一旦结构体字段多、列名不规则（比如含数字或特殊符号），json tag 完全不可靠
用 sqlx.DB.Rebind() 前先确认 driver 是否支持（如 postgres 用 $1，mysql 用 ?），否则 tag 写对了，占位符类型不匹配照样查不出数据

为什么 `NamedExec` 插入后拿不到自增 ID？

PostgreSQL 和 MySQL 处理方式不同：NamedExec 本身不返回 last insert id，必须用 QueryRowx + RETURNING（PG）或 LAST_INSERT_ID()（MySQL）显式获取。常见错误是以为 res, _ := db.NamedExec("INSERT INTO users(name) VALUES (:name)", arg) 后调 res.LastInsertId() 就能拿到——MySQL 可行，但 PostgreSQL 返回 0, sql.ErrNoRows。

正确做法是把插入和取 ID 合成一条语句：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

err := db.QueryRowx("INSERT INTO users(name) VALUES ($1) RETURNING id", name).Scan(&id)

注意点：

SQLite 用 RETURNING 语法不兼容，得改用 db.QueryRow("INSERT ...; SELECT last_insert_rowid()")
struct 中 ID 字段必须导出且有 db:"id" tag，否则 Scan 失败不报错，id 保持零值
事务中慎用 RETURNING：某些 PG 驱动在事务未提交时返回临时 ID，提交后可能变化（极少见，但高并发写入时需验证）

封装 Query 方法时，为什么泛型 `func Get[T any](...)` 容易出问题？

sqlx 本身不支持泛型，硬套 any 类型会导致反射开销上升、错误定位变难。最典型的问题是：泛型函数里调 db.Get(&v, query, args...)，但 v 是值而非指针，运行时报 reflect.Set: value of type T is not addressable。

根本原因是 Go 泛型擦除后，T 在运行时无法保证是指针类型，而 sqlx 所有 Scan 类方法都要求接收方为地址。

安全封装方式：只接受 interface{} 并强制断言为指针，或者用具体类型重载（如 GetUser、GetOrder）
别在泛型里调 db.Select：它内部用 reflect.Append，若切片元素类型与扫描目标不一致（比如 DB 返回 int64，结构体字段是 int），会静默失败
真正省事的封装不是泛型，而是复用 sqlx.DB 实例 + 统一 error wrap（例如用 fmt.Errorf("get user: %w", err)），而不是抽象掉 sqlx 原生行为

复杂点在于：sqlx 的便利性来自贴近原生 sql 的控制力，过度封装反而掩盖了 driver 差异、字段映射细节和错误语义——这些恰恰是调试时最需要的信息。