with recursive是语句级语法，必须作为顶层结构紧贴开头，不可嵌套于子查询或其它cte中；必须用union all合并锚点与递归部分；列数、类型、顺序须严格一致；需手动设终止条件（如level≤10）和防环机制，并确保连接字段有索引。
WITH RECURSIVE 不是嵌套查询的递归调用，而是独立的递归查询机制——它不能写在子查询里，也不能被其他 CTE 嵌套包裹，必须作为整个语句的顶层结构出现。
为什么不能把 WITH RECURSIVE 当成普通子查询用
很多人试图在 WHERE 或 FROM 里塞一个递归 CTE，比如：SELECT * FROM (WITH RECURSIVE ...)，这会直接报错。MySQL、PostgreSQL 都明确要求 WITH RECURSIVE 必须紧贴语句开头，后面紧跟主 SELECT（或 INSERT/UPDATE），中间不能插任何括号或嵌套层级。
-
WITH RECURSIVE是语句级语法，不是表达式，不支持物化或别名传递到外层作用域 - 想“复用”递归结果？只能把它定义为顶层 CTE，再在后续查询中
JOIN或IN引用，不能当子查询临时表嵌套 - 多个递归逻辑要并列？用逗号分隔多个 CTE，但每个
WITH RECURSIVE必须单独声明，不能共用一个WITH
UNION ALL 必须写，且不能换成 UNION
递归部分和锚点部分必须用 UNION ALL 合并，换成 UNION 会导致去重逻辑干扰迭代过程——比如某层节点 ID 重复出现（合法的树形结构中可能有同名但不同 ID 的节点，或路径拼接导致字符串重复），UNION 会删掉中间结果，下一层就查不到对应父节点，递归提前中断。
- 锚点部分返回根节点，比如
SELECT id, name, 1 AS level FROM org WHERE pid IS NULL - 递归部分必须显式包含相同数量、相同类型的列，
level字段要自增：SELECT o.id, o.name, c.level + 1 FROM org o JOIN cte c ON o.pid = c.id - 列顺序和类型必须严格一致，否则 MySQL 会报
ERROR 1248: Every derived table must have its own alias类似错误（实际是类型推导失败）
防环和限深：不加就等着超时
真实业务数据常有脏环（A→B→C→A），或者因 JOIN 条件宽松导致无限匹配。WITH RECURSIVE 没有默认终止机制，全靠你手动控制。
- 加
level 是最简单有效的深度限制，写在递归部分的 <code>WHERE里（锚点部分也得带该字段，否则类型不一致） - 用路径数组防环（PostgreSQL）：
ARRAY[id]初始，递归时array_append(c.path, o.id)，再加WHERE NOT o.id = ANY(c.path) - MySQL 没原生数组，改用字符串拼接：
CONCAT(c.path, '>', o.id)，配合NOT FIND_IN_SET(o.id, c.path)（注意FIND_IN_SET性能差，仅应急） - 索引必须落在连接字段上，比如
org(pid)，否则每轮迭代都全表扫描，10 层递归可能拖垮整个实例
从下往上查（反向递归）容易漏掉根节点
查某个子节点的所有上级时，锚点是子节点自身，递归条件是 ON c.pid = o.id（注意方向），但常见错误是只查到直接上级就停了——因为没把“当前节点”本身纳入结果集，或者递归条件写反。
- 锚点部分必须包含目标节点完整信息，包括它的
pid，否则无法继续向上找 - 递归部分要
JOIN org o ON c.pid = o.id，即用上层节点的id去匹配当前节点的pid - 路径拼接时，反向链路要前置追加：
CONCAT(o.id, '>', c.path)，否则顺序是倒的 - 如果目标节点本身就是顶级（
pid IS NULL），锚点能查出，但递归部分不会触发——这是正常行为，不代表逻辑错
递归真正难的不是语法，是判断哪一层该停、哪个字段该索引、环在哪里、路径怎么拼才不越界——这些没法靠模板解决，得看具体数据分布和查询意图。
