row_number() 无法直接处理树形结构层级关系，必须配合递归cte先计算level和可排序路径（如数组或字符串），再基于path排序生成序号；仅按id或level排序会导致父子顺序错乱。
ROW_NUMBER() 不能直接处理树形结构的层级关系
ROW_NUMBER() 是个窗口函数，只按指定 ORDER BY 生成连续序号，它不感知父子关系、不递归、也不理解路径深度。如果你直接对一张带 parent_id 的树表（比如组织架构或菜单）写 ROW_NUMBER() OVER (ORDER BY id)，得到的只是全局编号，和“第几层”“同级第几个”完全无关。
真正需要的是先展开树（用递归 CTE），再在展开结果上按层级+顺序打序号。核心思路是：先算出每行的 level 和合理的排序路径，再基于这两者做 ROW_NUMBER()。
必须配合递归 CTE 构建层级上下文
没有递归，ROW_NUMBER() 就没“层”的依据。PostgreSQL/SQL Server/Oracle/MySQL 8.0+ 都支持 WITH RECURSIVE，这是前提。
- 递归 CTE 中需显式计算
level（从 1 开始，每下一层 +1） - 推荐同时构建一个可排序的路径字段，比如
LPAD(id::TEXT, 10, '0')拼接，或更稳健地用数组/字符串累积：ARRAY[0] || id（PG）、CONCAT(path, '/', id)（MySQL） - 路径字段决定“同级谁排前”，避免仅靠
id排序导致子节点乱序（例如父节点 id=100，子节点 id=2 却排在 id=99 后面）
示例（PostgreSQL）：
WITH RECURSIVE tree AS ( SELECT id, parent_id, name, 1 AS level, ARRAY[id] AS path FROM menu WHERE parent_id IS NULL UNION ALL SELECT m.id, m.parent_id, m.name, t.level + 1, t.path || m.id FROM menu m JOIN tree t ON m.parent_id = t.id ) SELECT id, name, level, ROW_NUMBER() OVER (ORDER BY path) AS sort_order FROM tree ORDER BY path;
ORDER BY path 是分层排序的关键，不是 ORDER BY level
只按 level 排会导致所有 level=2 的节点挤在一起，失去父子嵌套顺序。真正反映树形遍历顺序的是 path 字段——它天然携带了 DFS（深度优先）顺序。
-
path = ARRAY[1,3,7]表示根→子→孙，应排在ARRAY[1,4]前面 - 若用字符串路径（如
'/1/3/7'），注意确保数字等宽或加前导零，否则'/1/10'会排在'/1/2'前（字典序问题） - SQL Server 中可用
HIERARCHYID类型替代手工 path，但兼容性差，多数场景还是字符串/数组更可控
ROW_NUMBER() 的粒度要匹配业务需求
同一个 ROW_NUMBER() OVER (ORDER BY path) 给出的是整棵树的全局序号。如果需要“每层内独立编号”，就得改用 PARTITION BY level：
ROW_NUMBER() OVER (PARTITION BY level ORDER BY path)
但要注意：
- 这会产生多个 1,2,3…，无法直接用于前端无限滚动或分页（因为跨层序号不连续）
- 若要“第 N 层的第 M 个节点”，通常还是用全局
sort_order更稳妥，再用应用层解析level和位置 - 性能上，
path字段若未建索引，ORDER BY 可能变慢；PostgreSQL 可对path数组建 GIN 索引，MySQL 则建议用生成列+普通索引
路径构造和排序逻辑一旦写错，ROW_NUMBER() 就只是个漂亮的错误序号——它不会报错，但结果完全不可信。
