WITH RECURSIVE 仅支持无权图最短跳数路径，无法实现带权图最短路径；因其缺乏状态维护、松弛更新和优先队列能力，不能模拟 Dijkstra 算法的贪心调度，强行使用易导致死循环、结果错误或性能崩溃。

WITH RECURSIVE 是目前主流 SQL 引擎中唯一能直接表达图遍历逻辑的机制，但它不能直接求出最短路径——它只能做无权图的 BFS 层级展开或带环检测的路径枚举。真正意义上的“最短路径”（即按边权累加最小）在纯 SQL 中无法用嵌套子查询或单次 WITH RECURSIVE 稳定求解，原因在于 SQL 缺乏状态维护、松弛更新和优先队列能力。

---

WITH RECURSIVE 只能做无权图的“最短跳数”路径

当你写：

WITH RECURSIVE path AS (
  SELECT id AS start, id AS end, 0 AS hops, CAST(id AS TEXT) AS route
  FROM nodes WHERE id = 'A'
  UNION ALL
  SELECT p.start, e.to, p.hops + 1, p.route || '->' || e.to
  FROM path p
  JOIN edges e ON p.end = e.from
  WHERE p.hops < 10  -- 必须设深度限制，否则可能死循环
)
SELECT * FROM path WHERE end = 'Z' ORDER BY hops LIMIT 1;

• 这里 hops 是跳数（边数），不是路径权重和；
• WHERE p.hops < 10 是硬性保护，防止负权环或强连通图导致无限递归；
• 即使你把边权塞进 hops 字段，也无法保证“第一次到达某节点时就是最短”，因为递归不按权重顺序展开，SQL 不支持 Dijkstra 那种“每次取当前最小距离节点”的贪心调度。

---

嵌套子查询对最短路径毫无帮助

试图用多层 (SELECT ... FROM (SELECT ...)) 模拟迭代：

• 无法跨层级传递中间最优距离（SQL 子查询是独立作用域）；
• 每层只能基于上一层的静态结果，不能做“若新路径更短则覆盖”的状态更新；
• 复杂度爆炸：n 层嵌套 ≈ 暴力枚举所有长度 ≤ n 的路径，O(|E|^n)，实际不可行。

常见错误现象：

• 查询跑满内存或超时；
• 返回的“最短”其实是任意一条可达路径，权重未必最小；
• 同一终点出现多次，但无法 GROUP BY end HAVING MIN(total_weight) 同时保留完整路径字符串（聚合与非聚合字段冲突）。

---

真实可行的折中方案

如果你必须用 SQL 解决带权图最短路径问题，且数据量不大（节点 < 500，边 < 2000），可考虑：

• 使用 WITH RECURSIVE 枚举所有从源点出发、总权值 < 某上限的路径（需预估合理上限），再用外层 ORDER BY SUM(weight) LIMIT 1 取最小；
• 示例关键结构：

  WITH RECURSIVE search AS (
    SELECT from_id, to_id, weight AS total_weight, ARRAY[from_id, to_id] AS path
    FROM edges WHERE from_id = 'A'
    UNION ALL
    SELECT s.from_id, e.to_id, s.total_weight + e.weight, s.path || e.to_id
    FROM search s
    JOIN edges e ON s.to_id = e.from_id
    WHERE array_length(s.path, 1) <= 10  -- 控制路径长度防爆
      AND s.total_weight + e.weight < 1000  -- 权重剪枝，依赖业务上限
  )
  SELECT path, total_weight
  FROM search
  WHERE to_id = 'Z'
  ORDER BY total_weight
  LIMIT 1;

• 性能/兼容性影响：
  • PostgreSQL 支持最好；MySQL 8.0+ 和 SQL Server 也行，但 SQLite 对递归深度默认限制严（PRAGMA recursive_triggers=ON 不够，还需调 max_recursive_depth）；
  • 边权为负时，该方法失效（可能漏掉更短路径，或因无上限陷入循环）；
  • 一旦图含负权环，结果不可信，且查询可能不终止。

---

Dijkstra 或 A* 的核心是“动态维护未访问节点中当前已知最小距离”，这需要可变状态和优先弹出——SQL 的声明式模型天然排斥这种过程式逻辑。真要落地，得把图导出后用 Python/Go 跑算法，再把结果回写数据库。强行在 SQL 里硬刚最短路径，最后卡在调试递归终止条件和权重剪枝阈值上，比换语言多花三倍时间。