sqlx不是ORM，仅增强database/sql；查单行必须用Get传结构体地址且字段带db tag，RETURNING需配Get/Select，命名参数仅通过NamedQuery/NamedExec安全使用。
sqlx 不是 ORM，它只是让 database/sql 更好用；如果你期望自动建表、关联加载或复杂查询构建，会踩坑。真正提升效率的点在于：结构体映射、命名参数、RETURNING 正确使用这三件事——其他都是锦上添花。
查单行必须用 Get，且传结构体地址 + db tag
直接调 QueryRow 或漏掉地址符，字段就扫不上。常见错误包括：
- 写
db.Get(user, ...)（没取地址）→ 字段全零值，不报错但数据为空 - 结构体字段没加
db:"xxx"tag，或 tag 值和 SQL 列名/别名不一致 → 字段映射失败，值保持零值 - SQL 里用了别名（如
SELECT id AS user_id），但 tag 写成db:"id"→ 扫不到 - 字段名默认按小写匹配，但数据库列是
user_name，结构体字段叫UserName却只写db:"username"→ 匹配失败
正确写法示例：
type User struct {
ID int64 `db:"id"`
Name string `db:"name"`
Email string `db:"email"`
}
var u User
err := db.Get(&u, "SELECT id, name, email FROM users WHERE id = ?", 123)
RETURNING 必须配 Get 或 Select，不能用 Exec
PostgreSQL 的 INSERT ... RETURNING 表面是插入，本质是带结果集的查询语句。用 Exec 调用只会静默丢掉返回值，还不会报错。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 想取单个字段（如新插入的
id）：var id int64; err := db.Get(&id, "INSERT INTO users(...) VALUES(...) RETURNING id", ...) - 想取多列：
type InsertResult struct { ID int64 `db:"id"` CreatedAt time.Time `db:"created_at"` }; var r InsertResult; db.Get(&r, query, ...) - MySQL / SQLite 不支持
RETURNING，只能靠Result.LastInsertId()（注意：仅 MySQL/SQLite 驱动实现该方法，PostgreSQL 驱动返回 0）
跨库写法建议：对 PostgreSQL 专用逻辑做分支，别强行统一。
命名参数只在 NamedQuery / NamedExec 中安全，裸写 :name 会 panic
:name 语法 PostgreSQL 原生支持，但 MySQL 和 SQLite 驱动根本不认。直接写 db.Query("SELECT * FROM u WHERE name = :name", map[string]interface{}{"name": "a"}) 在 MySQL 下会 panic。
- 要用命名参数，必须走
db.NamedQuery或db.NamedExec—— 它们内部调用sqlx.Rebind()把:name转成对应驱动的位置符（?或$1） - 传参用
map时，键名必须和 SQL 中:xxx完全一致（大小写、下划线、拼写都不能错），否则报driver: bad connection（实际是参数未匹配） - 事务中
NamedExec失败，优先检查：map 键名是否拼错、是否有nil值传入、对应字段是否允许 NULL
安全写法示例：
query := `INSERT INTO users (name, email) VALUES (:name, :email)`
params := map[string]interface{}{"name": "alice", "email": "a@b.c"}
_, err := db.NamedExec(query, params)
sqlx.Connect 和 sqlx.Open 的区别在连接可用性验证时机
sqlx.Open 和标准库 sql.Open 行为一致：只初始化驱动，不建真实连接；而 sqlx.Connect 会在返回前自动调一次 Ping，确保连接池至少有一个可用连接。
- 开发/测试环境推荐用
sqlx.Connect，避免启动后首次请求才暴露连接问题 - 生产环境若依赖连接池懒加载策略（比如配合 readiness probe 延迟探测），可用
sqlx.Open+ 后续手动db.Ping() - 两者返回的都是
*sqlx.DB，接口完全兼容，可混用
最容易被忽略的是：即使 Connect 成功，也不代表后续所有查询都一定成功——网络抖动、权限变更、连接超时仍会发生，错误处理不能省。
