Gorm 直接查树结构会出问题，因其不支持递归查询且 Preload 仅限单层预加载，易导致 panic 或空 Children；应使用原生 SQL 的 WITH RECURSIVE 递归 CTE 查询，并配合 level 字段构建层级树。
为什么直接用 Gorm 查树结构会出问题
因为 Gorm 默认不支持递归查询，也没有内置的 WITH RECURSIVE 语法封装。你写 Preload("Children") 只能查一层，嵌套两层就得手动写两次 Preload，三层就崩——这不是懒，是 SQL 层根本没生成正确的自关联查询。
常见错误现象：panic: reflect: call of reflect.Value.Interface on zero Value，往往是因为预加载字段为空但代码强行取 Children[0].Name；或者返回数据里 Children 始终是空切片，但数据库明明有子节点。
- 真实场景：菜单管理、组织架构、分类分级（如电商类目）
-
Gin路由里直接传c.Param("id")做根节点，但后端没做深度限制，容易触发 N+1 或无限递归 -
Gorm的Preload是 JOIN 查询，对深树效率差，且无法控制层级深度
用原生 SQL + WITH RECURSIVE 查任意深度
PostgreSQL 和 MySQL 8.0+ 都支持递归 CTE，这是查树最稳的方式。别绕弯，直接在 Gorm 里用 Raw 执行，再 Scan 到结构体。
假设表结构是 categories(id, name, parent_id)，要查以 id=5 为根的整棵树：
立即学习“go语言免费学习笔记（深入）”；
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;
- 必须显式传参用
db.Raw(sql, rootID).Scan(&nodes)，不能拼字符串，防注入 -
level字段一定要加，否则前端没法渲染缩进或折叠 - MySQL 8.0+ 才支持
WITH RECURSIVE，MariaDB 10.2+ 也行；SQLite 和旧版 MySQL 得换方案
用 Gin 返回带层级的 JSON 时注意字段平铺
递归 SQL 查出来的是扁平列表（每行一个节点 + level），但前端通常想要嵌套结构（{name: "A", children: [{name: "A1"}]}）。别在 SQL 里拼 JSON，交给 Go 处理更可控。
实操建议：
- 先用
db.Raw(...).Scan(&[]CategoryNode{})拿到带level的切片 - 写个简单函数按
level构建树：buildTree(nodes, rootLevel int)，用栈或 map 缓存父节点引用 -
Gin的c.JSON(200, treeRoot)直接返回，别用c.Render或模板 - 如果树很深（>1000 节点），避免用递归函数构建，改用 for-loop + map[int]*Node 缓存引用，防栈溢出
想用 Gorm 链式调用？得自己封装 FindTree
可以封装成模型方法，但别试图让 Gorm 自动生成递归 SQL。正确姿势是：在 Category 模型里加一个方法，内部调用原生 SQL + 构建逻辑。
示例签名：
func (c *Category) FindTree(db *gorm.DB, rootID uint, maxLevel int) (*CategoryNode, error) {
// 1. 执行带 maxLevel 限制的 WITH RECURSIVE（WHERE level <= ?）
// 2. Scan 进 []CategoryNode
// 3. buildTree(..., 0)
// 4. return root node
}
- 必须传
maxLevel参数，否则恶意请求传个超大rootID可能拖垮数据库 - 别把
db硬编码成全局变量，Gin中间件传*gorm.DB更测试友好 - 如果用 SQLite，只能靠多次查询模拟递归（查一层，再查下一层 ID 列表），性能差，建议直接换 DB
真正麻烦的不是怎么查，而是怎么安全地暴露树接口——level 限制、缓存头、ID 校验，这些漏掉一个，上线后就会被刷崩。
