sqlx 通过字段别名和 db 标签支持 JOIN 结果映射，但需手动处理一对多嵌套；sqlc 生成类型安全代码，字段齐全且零反射，但嵌套结构仍需自行封装转换。
用 sqlx 的 Unmarshal + 嵌套结构体直接映射 JOIN 结果
Go 原生 database/sql 不支持自动展开嵌套字段，但 sqlx 提供了 StructScan 和带标签的嵌套解析能力。前提是 SQL 字段名要能跟结构体字段对应上，且用下划线分隔（如 user_id → UserID），或显式加 db 标签。
常见错误是字段名冲突：比如 users.id 和 orders.id 都叫 id，扫描时会覆盖。必须用别名区分：
SELECT u.id AS user_id, u.name, o.id AS order_id, o.amount FROM users u JOIN orders o ON u.id = o.user_id
对应结构体写法：
type User struct {
ID int `db:"user_id"`
Name string `db:"name"`
Orders []Order `db:"-"` // 手动填充，sqlx 不自动展开一对多
}
<p>type Order struct {
ID int <code>db:"order_id"</code>
Amount float64 <code>db:"amount"</code>
}- 别名必须唯一，否则
sqlx.StructScan会静默丢掉后出现的同名字段 -
db:"-"表示跳过该字段，避免扫描时报错 - 一对多关系无法靠单次查询+单次
StructScan自动填充，得手动分组
一对多联查后手动分组填充嵌套切片
SQL 返回的是扁平结果集（N 条记录），而结构体需要一个 User 包含多个 Order。不能指望 ORM 式自动组装，得自己按主键聚合成 map，再转成目标结构。
立即学习“go语言免费学习笔记（深入）”；
典型场景：查用户及其所有订单，返回 []User，每个 User.Orders 是非空切片。
实操要点：
- 先用
sqlx.Select查出所有行，按user_id排序（方便后续分组） - 遍历结果，用
map[int]*User缓存已见的用户，遇到新user_id就新建，已有就追加Order - 最后把 map 值转成 slice，顺序可能和 SQL 不一致，如有需要可额外排序
性能影响：内存里做一次遍历，O(n)，比发 N+1 次查询好得多；但数据量极大（如单用户几万订单）时注意 GC 压力。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
用 sqlc 生成类型安全的 JOIN 查询代码
手写 SQL + 手动映射容易漏字段、错标签、类型不匹配。sqlc 能根据 SQL 文件生成 Go 结构体和查询函数，字段名、类型、嵌套全由 SQL 定义驱动。
使用前提：SQL 必须有明确别名，且命名符合 Go 风格（如 u.id AS user_id）。
配置示例（sqlc.yaml）：
version: "2" packages: - name: "db" path: "./db" queries: "./query/*.sql" schema: "./schema.sql"
SQL 文件里写：
-- name: GetUsersWithOrders :many SELECT u.id AS user_id, u.name, o.id AS order_id, o.amount FROM users u JOIN orders o ON u.id = o.user_id ORDER BY u.id;
生成后得到强类型函数 GetUsersWithOrders，返回 []struct { UserID int; Name string; OrderID int; Amount float64 } ——不是嵌套结构，但字段齐全、零反射、编译期报错。
- 想得到嵌套结构？得在生成后自己封装一层转换逻辑（和上一节一样）
- 兼容性好：
sqlc输出纯 Go 代码，不依赖运行时反射，适合高频查询服务 - 容易踩的坑：SQL 中漏写某个字段的别名，生成的 struct 就少字段，后续调用直接 panic
为什么不用 GORM 或 Ent 做 JOIN 映射
它们确实支持 Preload 或 EagerLoad，但底层仍是 N+1 或手动拼 JOIN + 复杂扫描逻辑。问题不在功能，而在可控性：
- GORM 的
Joins+Preload混用时，字段别名规则混乱，db标签常失效 - Ent 的
Select+With在 JOIN 后返回的Edge数据需二次 fetch，不是真的一次查完 - 调试困难：出错时你看到的是框架封装后的错误信息，比如
"can't scan into dest"，实际是字段名对不上 - 性能黑盒：框架自动加的
GROUP BY、DISTINCT可能拖慢查询，还不好改
复杂点永远在字段对齐和一对多聚合逻辑上，而不是选哪个库——哪怕用最原始的 rows.Scan，只要字段别名写清楚、分组逻辑写稳，结果一样准。
