sqlx是database/sql的增强层而非替代品，仅优化结构体映射、参数绑定和查询封装；误用（如期待自动重试）会引发隐性故障，且StructScan要求字段数与SELECT列数严格一致，字段须导出并推荐统一加db tag。
sqlx 不是替代 database/sql 的新驱动，而是它的增强层——它不改变连接池、事务语义或底层驱动行为，只在结构体映射、参数绑定和查询封装上省掉样板代码。用错地方（比如指望它自动重试或管理连接生命周期）反而会引入隐性故障。
StructScan 要求字段数与 SELECT 列数严格一致
常见 panic："sql: expected 2 destination arguments, got 1"。这不是 sqlx 的 bug，而是 StructScan 的硬约束：它按列名（或 db tag）匹配字段，且必须一一对应。
- SELECT 字段顺序和数量必须与结构体导出字段完全一致；推荐显式写出字段，避免
SELECT *带来的脆弱性 - 结构体字段必须首字母大写（导出），且建议统一加
dbtag，例如ID int `db:"id"`，避免依赖数据库列名大小写 - 只查统计值等单列结果时，别硬套完整结构体，改用
Scan：var count int; err := db.QueryRowx("SELECT COUNT(*) FROM users").Scan(&count)
Get 和 Select 的目标变量必须是指针类型
Get 和 Select 是 QueryRowx/Queryx + StructScan 的封装，但封装带来了明确的类型要求。
-
Get(&user)中&user必须是单个结构体指针，不能传值 -
Select(&users)中&users必须是指向切片的指针，即[]User类型的变量地址；传[]User值会导致 panic - 切片元素类型本身必须是结构体指针（如
[]*User）才能被StructScan正确写入；但Select内部已处理这点，外部只需传*[]User
sqlx.In 处理 IN 查询必须两步走
IN (?) 不能直接传 slice，原生 database/sql 会报 "unsupported type []string"。sqlx.In 是唯一正解，但它分两步，漏一步就失败。
立即学习“go语言免费学习笔记（深入）”；
- 先调用
sqlx.In("SELECT * FROM users WHERE id IN (?)", ids)，返回带占位符的 SQL 字符串和展开后的参数切片 - 再用
db.Rebind()适配驱动占位符风格：MySQL 用?，PostgreSQL 用$1, $2；没这步，PostgreSQL 直接报错"pq: syntax error at or near "?" - 最终执行必须用
db.Select(&users, sql, args...)—— 注意args...是展开的，不是传整个切片 - 空 slice 是高频坑点：
sqlx.In对空 slice 返回"WHERE id IN ()"，多数数据库语法不支持；需提前判断并跳过查询或改用WHERE 1=0
命名参数不等于万能，嵌套 map 或 slice 无法自动展开
NamedQuery 和 BindNamed 支持 map[string]interface{} 或结构体，但仅限一层扁平展开。
- 不能传
map[string]interface{}{"user": map[string]string{"name": "a"}}，BindNamed不识别嵌套结构 - slice 参数仍需配合
sqlx.In，命名参数本身不支持:ids...这类展开语法 - 复杂条件逻辑（如动态 WHERE 子句）仍得拼 SQL 或组合
sqlx.In+ 手动构建参数 map
sqlx 的价值在于减少重复映射代码，但它的约束也真实存在：字段匹配、指针传递、占位符重写、空 slice 处理——这些不是文档角落里的备注，而是日常写查询时立刻撞上的墙。绕开它们靠的不是技巧，而是每次写 Get 或 IN 之前，多看一眼参数类型和 SQL 结构。
