preload 并非简单添加即可提升性能，需配合 select、where、limit 及层级克制才能生效；其慢因在于默认 in 子查询在嵌套时导致 id 列表爆炸式膨胀，引发 mysql 报错或传输解析变慢。
Preload 不是加了就快，用错反而比 N+1 还慢；它必须配合 Select、Where、Limit 和层级克制才能真正生效。
Preload 为什么有时比循环查还慢？
根本原因在于 GORM 默认用 IN 子查询做批量关联加载，但链式嵌套会让 IN 列表爆炸式膨胀。
- 比如
db.Preload("Orders").Preload("Orders.Items") - 100 个用户 × 平均 20 笔订单 = 2000 个订单 ID
- 第二层
Items 查询的 <code>WHERE order_id IN (…)就要传 2000 个 ID - MySQL 可能直接报错
Packets larger than max_allowed_packet are not allowed - 即使没报错，网络传输、SQL 解析、内存组装都会明显变慢
必须带 Select：否则字段越多越拖垮性能
默认 Preload("User") 会拉回整个 User 表所有字段，但接口往往只需要 name 和 avatar_url。
-
Select必须包含外键或主键（如id或user_id），否则 GORM 关联失败 - 宽表（30+ 字段）场景下，
db.Preload("User", func(db *gorm.DB) *gorm.DB { return db.Select("id", "name", "avatar_url") })能让响应体积下降 70%~90% - 避免在
Select中漏掉关联所需的外键字段，比如user_id没选，User就无法正确绑定到Post
带条件预加载：别加载不需要的数据
多数业务场景并不需要“全部关联记录”，比如只取最近 3 笔已支付订单，或仅判断是否存在有效订单。
- 带过滤和排序：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Order("created_at DESC").Limit(3) }) - 仅判断存在性（更轻量）：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Select("id").Limit(1) }) - 慎用
ORDER BY却不配LIMIT——排序本身便宜，返回全量结果集才是开销大头
深度嵌套 Preload("A.B.C") 的真实约束
v1.9.11+ 版本确实支持多级链式预加载，但稳定运行的前提是结构体定义和标签完全规范。
- 嵌套路径中每一级都必须是 GORM 可识别的关联字段，不能是普通字段或未声明
gorm:"foreignKey:..."的指针 - 常见报错
can't find field XXX in []**main.YYY多因[]*Low中的Bottom字段类型不匹配（比如写成Bottoms []Bottom却没加gorm:"foreignKey:LowID"） - 三层以上嵌套（如
User.Orders.Items.Product）极易引发 IN 列表膨胀和内存重复数据，建议优先考虑分步查询或 Joins + 手动映射
最常被忽略的一点：Preload 是批量 IN 查询，不是 JOIN；它不保证事务一致性，也不支持跨库关联。如果业务强依赖原子性或需精确控制 SQL，得切回 Joins 或原生 SQL。
