GORM不支持WITH RECURSIVE DSL封装，必须用db.Raw()手写SQL实现树形查询；PostgreSQL和MySQL 8.0+支持该语法，但SQLite和MySQL 5.7不支持；分页需先取ID列表再查详情，不可直接在外层加LIMIT OFFSET。
递归查询必须自己写 SQL，GORM 不支持原生 WITH RECURSIVE
GORM 官方至今（v1.25 / v2.2+）未提供对 WITH RECURSIVE 的 DSL 封装。想查树形结构的全路径、所有子节点或祖先链，不能依赖 Preload 或 Joins 自动推导——它们只做 JOIN，不处理递归逻辑。
实际做法是：用 db.Raw() 手写带 WITH RECURSIVE 的 SQL，再 Scan 到结构体。注意 PostgreSQL 和 MySQL 8.0+ 支持该语法，但 SQLite 和 MySQL 5.7 不支持，硬切会报错 ERROR: syntax error at or near "WITH" 或 ERROR 1064 (42000)。
- PostgreSQL 示例（查某节点的所有后代）：
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;
- MySQL 8.0+ 需显式加
RECURSIVE关键字，且初始查询不能含聚合或 LIMIT；PostgreSQL 可省略RECURSIVE（但建议写上，增强可读性） - 别把递归结果直接
Find(&results)——GORM 的Find不识别Raw查询的字段映射，必须用Scan：var results []CategoryWithLevel db.Raw(sql, rootID).Scan(&results)
分页不能套在 WITH RECURSIVE 外层直接用 LIMIT OFFSET
递归 CTE 本身是一个逻辑结果集，如果在外层加 LIMIT 10 OFFSET 20，只会截断最终扁平结果，丢失树形层级完整性——比如第 21 行可能是某个子树的中间节点，导致其子节点全部被丢弃，数据断裂。
真正安全的分页方式只有两种：
- 先取完整递归结果 ID 列表，再分页查详情：用子查询生成 ID 数组，再 JOIN 主表分页。适合结果集不大（
-
按层级 + 排序规则做“游标分页”：例如记录上一页最后的
(level, id)，下一页查WHERE (level, id) > (?, ?) ORDER BY level, id LIMIT 10。避免 OFFSET 跳跃，也保层级连续 - 千万别在递归 SQL 里写
WITH RECURSIVE ... SELECT * FROM tree LIMIT 10 OFFSET 20——多数数据库会报错，PostgreSQL 允许但语义错误，MySQL 直接拒绝
Preload 无法替代递归查询，但可优化“有限深度”的关联加载
如果业务只要查“当前节点 + 下两级子节点”，不用递归，用 Preload 配合 Where 和 Limit 更轻量：
db.Preload("Children", func(db *gorm.DB) *gorm.DB {
return db.Where("status = ?", "active").Limit(10)
}).Preload("Children.Children", func(db *gorm.DB) *gorm.DB {
return db.Where("status = ?", "active")
}).First(&category, "id = ?", id)但要注意：Preload 是 N+1 查询模拟（实际发多条 SQL），不是单次 JOIN；若子节点有 100 个，每个又有 100 个孙节点，会触发 100 次子查询，容易打爆连接池。此时必须回归手写 JOIN 或递归 SQL。
- MySQL 中
Preload的Limit在子查询里生效，但 PostgreSQL 可能忽略（取决于 GORM 版本），建议统一用Joins+Group+Having控制 - 所有
Preload字段名必须与 struct tag 中的gorm:"foreignKey:ParentID"完全一致，拼错会导致静默跳过，无报错无数据
递归 + 分页组合时，count 总数极难准确获取
你想显示 “共 127 条”，但递归结果是动态生成的，没法像普通表那样走 SELECT COUNT(*)。常见错误是：对递归 SQL 套一层 SELECT COUNT(*) FROM (WITH RECURSIVE ...)——这在 PostgreSQL 可行，MySQL 8.0+ 要求外层 SELECT 必须有别名，否则报 Every derived table must have its own alias。
更现实的做法是：
- 接受“总数不可知”，只提供“是否有下一页”：查
LIMIT N+1，若返回 N+1 条，则有下一页，第 N+1 条丢弃 - 缓存递归结果总数到 Redis，每次树结构变更（增/删/改 parent_id）时用 Lua 脚本原子更新，避免每次查都执行完整递归
- 如果层级固定（如最多 4 层），可预先建物化路径字段（
path VARCHAR(255)，存"1/5/23/"），此时 count 变成普通前缀匹配：SELECT COUNT(*) FROM categories WHERE path LIKE '1/5/%'
路径字段方案简单高效，但要求业务能接受写时多一次字符串拼接，且迁移历史数据需批量补全 path。
