preload 不适用于报表查询，因其为对象建模设计，无法支持 group by、sum 等聚合操作，且易引发 in 查询膨胀、内存重复、宽表全量加载等问题；报表应改用 joins + scan 手动控制 sql。
为什么直接用 Preload 做报表查询经常翻车
因为 Preload 本质是为「对象建模」服务的，不是为「聚合统计」设计的。它默认把关联数据当完整实体加载，而报表往往只需要几个字段、带条件过滤、还要分组求和——这时候 Preload 不但没用，反而拖慢查询、撑爆内存。
典型翻车现象：Preload("User").Preload("Order.Items") 在 100 个用户 × 50 订单 × 10 商品场景下，会生成含 5000 个 ID 的 IN 子句，触发 MySQL 的 Packets larger than max_allowed_packet are not allowed 错误；即使不报错，传输和解析开销也极大。
- 预加载无法做
GROUP BY或SUM()这类聚合操作 - 关联字段若未显式
Select，GORM 会拉回整张宽表（比如 30+ 字段的users表），响应体积激增 -
Preload的嵌套层级越深，内存中重复数据副本越多（1 用户 + 10 订单 → 内存里出现 10 次用户基础信息）
用 Joins + Scan 写报表查询的硬核写法
报表类需求，应该绕过 ORM 的对象映射层，直击 SQL 表达力。GORM 的 Joins + Scan 组合就是为此准备的：你控制表、字段、条件、别名，GORM 只负责执行和映射到结构体。
例如统计「近 30 天各城市订单总金额与订单数」：
type CityOrderStat struct {
City string `gorm:"column:city"`
Total float64 `gorm:"column:total"`
Count int64 `gorm:"column:count"`
}
var stats []CityOrderStat
err := db.Table("orders").
Select("u.city, SUM(o.amount) as total, COUNT(*) as count").
Joins("JOIN users u ON u.id = o.user_id").
Where("o.created_at >= ?", time.Now().AddDate(0,0,-30)).
Group("u.city").
Scan(&stats).Error
- 必须用
Table("orders")显式指定主表，否则Joins可能失效 -
Select中的别名（如as total）要和结构体字段的gorm:"column:xxx"标签严格对应 - 聚合函数（
SUM、COUNT）和GROUP BY必须成对出现，GORM 不会帮你补
LEFT JOIN 和 WHERE 条件顺序决定数据完整性
报表常需“展示所有城市，哪怕没订单”，这时要用 LEFT JOIN，但一不小心就把左连接写成了内连接——罪魁祸首往往是 WHERE 条件放错了位置。
错误写法（过滤条件写在 WHERE）：
db.Table("cities").
Select("c.name, COALESCE(SUM(o.amount), 0)").
Joins("LEFT JOIN orders o ON o.city_id = c.id").
Where("o.status = ?", "paid"). // ❌ 这会让 NULL 订单行被过滤掉
Group("c.name")
正确写法（把关联过滤移到 ON 子句）：
db.Table("cities").
Select("c.name, COALESCE(SUM(o.amount), 0)").
Joins("LEFT JOIN orders o ON o.city_id = c.id AND o.status = ?", "paid").
Group("c.name")
-
LEFT JOIN的语义是：保留左表全部记录，右表匹配不上则填NULL - 一旦在
WHERE里对右表字段做非空判断（如o.status = 'paid'），SQL 引擎会把NULL行全踢掉，等效于INNER JOIN - 想保留左表、又只统计右表某类记录？条件必须塞进
ON，而不是WHERE
字段别名和类型对齐是 Scan 成败的关键
Scan 不像 Find 那样依赖模型标签自动推导，它靠的是列名（或别名）与结构体字段的精确匹配。稍有偏差，字段就为零值，且无任何错误提示。
- 结构体字段必须导出（首字母大写），否则
Scan无法赋值 - 数据库返回的列名（或
AS别名）必须和gorm:"column:x"的x完全一致，大小写敏感 - 聚合结果类型要和 Go 字段类型兼容：比如
COUNT(*)返回int64，Go 字段就得是int64，不能是int（尤其在 Windows 上易出问题） - 涉及
NULL的字段（如左连接中可能为空的金额），建议用指针类型（*float64）或sql.NullFloat64，避免零值误判
复杂报表的真正难点不在语法，而在 SQL 语义的严谨性——ON 和 WHERE 的边界、NULL 的传播规则、聚合后字段类型的隐式转换，这些地方一松懈，数据就 quietly wrong。
