Preload("A.B.C") 返回空切片的根本原因是GORM未识别嵌套路径，要求每级字段导出、类型匹配、标签完整，且中间表必须显式创建并字段命名严格一致。
Preload("A.B.C") 为什么返回空切片
根本不是 SQL 没发，而是 GORM 没识别到嵌套路径——Preload("Articles.Tags.Categories") 要求每一级字段都必须是导出的、类型匹配的、且标签完整。常见断点：
-
Tags字段在Article结构体中漏了gorm:"many2many:article_tags;"，或中间表名写成articles_tags（复数错配） - 中间表结构体
ArticleTag中字段名不等于数据库列名，比如列是article_id，但结构体写ArticleID uint却没加gorm:"column:article_id" -
Tag结构体里的Categories是[]Category，但没声明gorm:"many2many:tag_categories;"，或tag_categories表本身没被AutoMigrate过 - GORM 版本低于 v1.9.11 —— 该版本前对三级以上嵌套的反射解析会静默失败，不报错也不查数据
验证方式：开 SQL 日志，看是否有类似 SELECT * FROM categories WHERE tag_id IN (?) 的第三条查询；没有，说明 Categories 这一级根本没注册。
Joins + Preload 混用会踩什么坑
不能混用。一旦用了 Joins("JOIN orders ON ...")，再跟 Preload("Orders")，GORM 会忽略 Preload，因为 Joins 已经改变了查询上下文。更危险的是，你可能误以为 user.Orders 被填充了，其实还是空切片。
-
Joins只生成 JOIN SQL，不会把关联行映射进嵌套字段；Preload才负责填充[]Order - 想查扁平结果（如用户+订单标题），用
Joins+Select("users.*, orders.title")+ 自定义 struct 接收 - 想查嵌套结构（如
user.Orders[0].Items），必须全链路用Preload，禁用Joins - 若主表需带条件（如只查 status=active 的用户），
Where("users.status = ?", "active").Preload("Orders")是安全的；但Where("orders.status = ?")会作用于主查询，导致无匹配时整行丢失
多对多嵌套 Preload("A.B.C") 的硬性前提
不是写对语法就行，中间表结构体必须“可反射”：所有字段首字母大写、有明确类型、外键字段存在且命名与数据库列严格一致。
立即学习“go语言免费学习笔记（深入）”；
- 中间表结构体（如
ArticleTag）不能含未导出字段；ArticleID uint✅，articleID uint❌ - 必须显式调用
db.Migrator().CreateTable(&ArticleTag{})，否则 GORM 不知道这张表存在，Preload("Articles.Tags")会跳过它 -
Tags字段在Article中声明为[]Tag `gorm:"many2many:article_tags;"`，而Tag中的Categories必须也带many2many标签，不能靠默认推导 - 如果
Categories是一对多（非多对多），那字段就得改用gorm:"foreignKey:TagID"，和多对多写法互斥
嵌套层级越深，IN 查询膨胀越猛
Preload("A.B.C") 默认走三轮独立 IN 查询：A 查一次 → 提取全部 A.ID → 查 B → 提取全部 B.ID → 查 C。100 个 A，每个关联 5 个 B，每个 B 关联 10 个 C，第三轮就要传入 5000 个 ID —— 数据库可能直接拒绝执行。
- 优先拆成两步：先
Preload("A.B")，拿到bIDs := []uint{...}，再Where("b_id IN ?", bIDs).Find(&cs) - GORM v1.25+ 支持
Preload("B", db.Limit(100))控制子查询条数，但仅限一级；多级仍需手动分治 - 高频组合（如文章+标签+分类）建议建物化视图，或冗余字段（如
article.tag_count），避免每次查都穿透三层
多级嵌套真正的难点不在语法，而在中间表是否被 GORM 完整识别——漏一个 column: 标签，或少一次 CreateTable，整个链就断在第二级，且不报错。
