preload必须紧挨find等终态方法前链式调用，顺序颠倒即失效；字段名大小写、嵌套路径、多对多中间表与主键均须严格匹配，否则静默失败。
Preload 必须链式调用在 Find 前
Preload 不是配置项，也不是装饰器，它只在链式调用中生效，且必须紧挨着 Find、First、Take 等终态方法之前。顺序颠倒就完全无效。
常见错误现象：db.Find(&users).Preload("Orders") —— 此时 users[0].Orders 仍是空切片，因为 Find 已执行完毕，Preload 被忽略。
-
db.Preload("Orders").Find(&users)✅ 正确 -
db.Where("active = ?", true).Preload("Orders").Find(&users)✅ 支持前置条件 -
db.Preload("Orders").Limit(10).Find(&users)✅ Limit 不影响 Preload 逻辑
字段名大小写与结构体定义必须严格一致
GORM 不做自动推导或容错，Preload("Users") 和 Preload("users") 是两个不同字段；Users []User 和 User User 也不能混用。错一个字母，关联静默失败，对应字段保持 nil 或空切片。
使用场景：调试时发现 group.Users 始终为空，但结构体里明明写了 Users []User —— 先检查字段名是否拼写正确、首字母大小写是否匹配。
- 结构体中字段是
Profiles []Profile，Preload 就必须写Preload("Profiles") - 若字段是
Owner User（一对一），不能写成Preload("owner")或Preload("Owners") - 嵌套预加载如
Preload("Users.Posts")，要求Users和Posts字段名都准确无误
多对多预加载依赖中间表与主键规范
多对多（如 Book ↔ Tag）无法靠命名自动识别，GORM 需要明确的中间表名 + 双方主键字段。最常被忽略的是：所有被关联模型必须有可识别主键（gorm.Model 或显式 gorm:"primaryKey"）。
容易踩的坑：Tag 结构体没加 gorm.Model 或没声明 ID int `gorm:"primaryKey"`，导致 Preload("Tags") 返回空切片，且不报错。
- Book 模型中
Tags []Tag `gorm:"many2many:book_tags;"`—— 中间表名小写+下划线（推荐） - Tag 模型必须含主键：
ID uint `gorm:"primaryKey"`或直接嵌入gorm.Model - AutoMigrate 会建
book_tags表，但不会自动加索引；建议手动加复合索引：CREATE INDEX idx_book_tags_book_id ON book_tags(book_id);
带条件的 Preload 必须 Select 外键或主键字段
加 WHERE 条件本身没问题，但若未显式 Select 关联所需的外键或主键字段，GORM 无法把子记录绑定到主记录上，结果仍是空切片。
性能影响：默认全字段 SELECT 会显著拖慢响应，尤其宽表（30+ 字段）。实测 Select 关键字段后，P95 延迟可从 320ms 降到 90ms。
- 正确写法：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Select("id", "user_id", "amount") }).Find(&users) - 只判断存在性？用
.Select("id").Limit(1)，比全量加载快得多 - 排序必须配
Limit：.Order("created_at DESC").Limit(3)，否则仍拉回全部数据
Preload("Users.Orders.Items.Product") 看似方便，实际极易触发笛卡尔积和 Packets larger than max_allowed_packet 报错。真正需要三层嵌套前，先确认前端是否真的要渲染完整树形结构。
