sqlx的Get和Select通过反射+db标签实现结构体自动映射，替代database/sql的手动Scan；要求字段导出、显式db标签（如db:"id"），否则静默置零。
Go 中用 sqlx 的 Get 和 Select 自动映射结构体
Go 标准库 database/sql 本身不支持自动映射，必须手动 Scan；真正能“自动映射”的是第三方库 sqlx —— 它在保持兼容 database/sql 的前提下，通过反射+结构体标签实现字段对齐。
常见错误是直接用 rows.Scan(&v) 传入结构体指针却没展开字段，结果 panic 或零值填充。正确做法是让 sqlx 知道如何把列名匹配到结构体字段：
- 结构体字段必须是导出的（首字母大写）
- 推荐显式加
db标签，比如type User struct { ID int `db:"id"` Name string `db:"name"` } - 列名默认按字段名小写匹配，但大小写敏感且不处理下划线转驼峰；加
db标签是最稳的方式 -
sqlx.Get用于单行查询（SELECT ... LIMIT 1），sqlx.Select用于多行，两者都要求目标结构体切片或变量地址正确传入
示例：
var user User err := db.Get(&user, "SELECT id, name FROM users WHERE id = $1", 123)—— 成功则
user 字段被填满；失败则 err 非 nil。
为什么不用 gorm 的 Find？它也能自动映射
gorm 确实提供更“全自动”的体验，比如 db.First(&user, 123) 不用写 SQL，还能自动处理关联、钩子、软删除等。但它引入了 ORM 层抽象，代价是：
- SQL 控制力下降：复杂 JOIN 或窗口函数容易绕弯，调试时难看清实际执行语句
- 性能开销：每条查询都经过 GORM 的中间层解析、日志、回调链，简单场景下比
sqlx多 10%~20% 延迟 - 隐式行为风险：比如
gorm.Model(&User{}).Select("name").Where("id = ?", 123).First(&u)可能因字段未导出或标签缺失而静默忽略赋值
如果你只需要读取、映射、返回，没有复杂关联或写操作编排，sqlx 更轻、更可预测。
sqlx 映射失败的典型错误和排查点
映射“看似成功但字段为空”是最常遇到的问题，根源几乎都在列名与结构体字段对不上：
- SQL 中用了别名但结构体没对应标签，例如
SELECT u.id AS user_id→ 结构体字段仍需`db:"user_id"`，不能只靠ID - 数据库列名含大写字母或特殊字符（如
"CreatedAt"），而结构体字段是CreatedAt，但没加db标签，sqlx默认按小写匹配，变成createdat，找不到就跳过 - 用了
SELECT *但表结构变更后新增列，结构体没同步更新，sqlx会忽略未知列，不报错也不提示 - 扫描目标是值而非指针，比如写成
db.Get(user, ...)（少&），会导致编译通过但运行时 panic：“reflect.Set: value of type User is not assignable to type *User”
建议开发期加一行日志：db.Unsafe().BindNamed(...) 可打印绑定详情，或开启 sqlx 调试模式看实际字段匹配过程。
嵌套结构体和切片字段能自动映射吗？
不能。标准 sqlx 的 Get/Select 只支持一层平铺结构体映射。比如：
type Order struct { ID int `db:"id"` User User `db:"?"` } —— 这里的 User 字段不会被自动填充，db:"?" 是占位写法，实际无效。
- 若需嵌套数据，必须拆成多条查询，或用
JOIN+ 手动构造（比如SELECT o.id, u.name as user_name，再定义UserOrder struct { ID int; UserName string }） - 切片字段同理，
[]string或[]int无法从单列 JSON 或数组类型直接解包，得用json.RawMessage或pgtype.TextArray等专用类型配合自定义Scan - 如果真需要深度嵌套，
sqlc（代码生成）或ent是更合适的选型，它们在编译期生成类型安全的映射逻辑，而非运行时反射
字段嵌套不是语法限制，而是设计取舍：保持映射逻辑简单、可预期，避免反射穿透多层带来的歧义和性能损耗。
