GORM 的 Preload 无法直接查出完整树形结构，因其默认仅支持单层关联加载，不递归加载子节点的后代，需用 WITH RECURSIVE 原生 SQL 查询再在 Go 层组装树。
为什么 GORM 的 Preload 无法直接查出完整树形结构
GORM 的 Preload 默认只做一层关联加载，比如父节点查出后，只会加载它的直接子节点；而子节点的子节点（孙子）不会被自动递归加载。这不是 bug，是设计使然——无限递归可能引发 N+1、内存爆炸或循环引用。如果你写了 db.Preload("Children").Find(&nodes) 却发现只有两级数据，就是这个原因。
常见错误现象：Children 字段在二级之后全为空；用 json.Marshal 输出时树深度永远卡在 2 层；调试时发现 SQL 只生成了 1 次 JOIN 或 1 次 IN 查询。
- 必须手动控制递归深度，GORM 不提供
Preload("Children.Children.Children")这种动态无限展开语法 - 嵌套调用
Preload（如链式写Preload("Children").Preload("Children.Children")）虽可行，但深度写死、难以复用 - 若用
Joins，会因自连接限制（如 MySQL 对同一张表多次 JOIN 的别名要求）导致 SQL 复杂且难维护
用 Raw SQL + WITH RECURSIVE 实现真正递归查询（推荐）
PostgreSQL 和 MySQL 8.0+ 支持 WITH RECURSIVE，这是查树最可靠的方式。GORM 允许原生 SQL 查询并 Scan 到结构体，绕过 ORM 关联逻辑的限制。
假设你的模型是：
type Category struct {
ID uint `gorm:"primaryKey"`
Name string
ParentID *uint `gorm:"index"`
}
查以 ID=1 为根的完整子树（含所有后代），可这样写：
var results []struct {
ID uint
Name string
ParentID *uint
Level int // 用于标识深度，可选
}
err := db.Raw(`
WITH RECURSIVE tree AS (
SELECT id, name, parent_id, 0 AS level
FROM categories
WHERE id = ?
UNION ALL
SELECT c.id, c.name, c.parent_id, t.level + 1
FROM categories c
INNER JOIN tree t ON c.parent_id = t.id
)
SELECT * FROM tree ORDER BY level, id
`, rootID).Scan(&results).Error
- 注意：MySQL 要求递归查询必须有终止条件（这里靠
parent_id为 NULL 自然终止），且需开启cte_max_recursion_depth - PostgreSQL 默认支持，但深度超 100 时建议加
SEARCH DEPTH FIRST BY id SET ordercol防止栈溢出 - 返回的是扁平列表，你需要在 Go 里用 map 构建树（见下一部分）
从扁平结果重建树结构（Go 层组装）
数据库只负责把所有相关节点按层级顺序查出来，组装成嵌套结构是 Go 的事。关键点是避免反复遍历：
- 用
map[uint]*Category缓存所有节点指针，O(1) 查找父节点 - 遍历时，如果
ParentID为空，则为根；否则从 map 中取父节点，将当前节点 append 到其Children切片 - 不要用递归函数去“找孩子”，那又变回 N² 复杂度；一次遍历 + map 查找即可
示例片段：
type Category struct {
ID uint `gorm:"primaryKey"`
Name string
ParentID *uint `gorm:"index"`
Children []*Category `gorm:"-"` // 不映射到 DB
}
<p>func BuildTree(flat []Category) []<em>Category {
nodes := make(map[uint]</em>Category)
var roots []*Category</p><pre class="brush:php;toolbar:false;">// 第一遍：全部入 map
for i := range flat {
nodes[flat[i].ID] = &flat[i]
}
// 第二遍：挂载关系
for i := range flat {
node := &flat[i]
if node.ParentID == nil {
roots = append(roots, node)
} else if parent, ok := nodes[*node.ParentID]; ok {
parent.Children = append(parent.Children, node)
}
}
return roots}
使用 GORM Scope 或 Callback 预埋树查询逻辑
把递归查询封装成可复用的方法，比每次写 Raw SQL 更安全。GORM 的 Scope 是合适载体：
func WithTree(rootID uint) func(db *gorm.DB) *gorm.DB {
return func(db *gorm.DB) *gorm.DB {
var results []Category
db.Raw(`...`).Scan(&results) // 同上 WITH RECURSIVE
tree := BuildTree(results)
// 注意：这里不能直接 return db.Model(&tree)，因为 tree 是运行时构建的
// 建议返回 []Category 并由调用方处理，或定义新方法如 FindTree(db, rootID)
return db
}
}
更实用的做法是写一个独立函数：
func FindCategoryTree(db *gorm.DB, rootID uint) ([]*Category, error) {
// 执行 WITH RECURSIVE 查询 → 得到 flat []Category
// 调用 BuildTree → 返回 *[]*Category
// 错误统一处理
}
- 不要试图在
BeforeFindcallback 里塞递归逻辑，它不适用于这种非标准关联场景 - 如果项目同时支持 SQLite（无 WITH RECURSIVE），得 fallback 到多次查询（先查 root，再查 children，再查 grandchildren…），此时必须限制最大深度防 DoS
- 缓存整棵树时，注意
ParentID和Children字段的 JSON 标签是否冲突（例如json:",omitempty"可能漏掉空数组）
递归树真正的复杂点不在 SQL，而在「何时触发查询」和「如何避免重复构建」——比如同一个树被多个 API 同时请求，没加缓存就容易打爆 DB。这些不在 GORM 能力范围内，得靠业务层兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
