在处理带有层级从属结构的数据时，我们经常会遇到这样的需求：每条记录通过parent_id指向自己的父级，同时自身携带一个分组字段（例如issue，表示最初上报的问题编号）。目标是从扁平的列表中推导出从根节点到当前节点的完整层级路径，并且把原始的issue字段继续关联在对应的记录上，便于后续按问题维度做聚合分析。
一、问题模型与数据结构
假设我们从数据库或接口拿到一组节点，每个节点至少包含三个核心字段：自身的唯一标识id、指向父节点的parent_id（根节点的parent_id为null或0）、以及业务分组字段issue。这种结构在工单系统、组织架构、评论盖楼等场景中非常普遍。问题在于，单条记录只知道“我的上一级是谁”，并不知道“我和根之间隔了几层、整条链路是什么”。
如果直接通过数据库的递归查询（如MySQL的WITH RECURSIVE）固然能解决，但在应用层做一次性处理往往更灵活，尤其是当数据已经加载到内存、或者需要结合其他内存对象做计算时。我们需要一种不依赖数据库递归、纯靠代码构建树并回溯路径的通用做法。
1.1 示例输入数据
下面是一段模拟的Java风格输入列表，为了清晰起见使用伪结构展示。实际开发中可能是List<Node>，其中Node类含有id、parentId、issue属性。
// 模拟节点定义
class Node {
String id;
String parentId; // 根节点为 null
String issue; // 原始分组字段，如问题编号
}
// 扁平输入
List<Node> flatList = Arrays.asList(
new Node("1", null, "ISS-100"),
new Node("2", "1", "ISS-100"),
new Node("3", "2", "ISS-100"),
new Node("4", null, "ISS-200"),
new Node("5", "4", "ISS-200")
);
二、构建内存索引与树形关联
第一步是为所有节点建立id到对象的快速索引，同时把每个节点挂到其父节点的children集合中。这一步只需一次遍历，时间复杂度为O(n)，空间上多消耗一个Map来存储引用，不会复制对象本身。
值得注意的是，原始issue字段在构建树时不应被覆盖或丢失。由于同一个父链下的节点往往共享同一个issue（例如工单流转过程中issue不变），我们可以在挂载时直接保留节点自带的issue值。即便出现子节点issue与祖先不同的情况，本实现也以节点自身issue为准，保证原始分组字段的准确关联。
2.1 索引与挂载代码
Map<String, Node> nodeMap = new HashMap<>();
for (Node n : flatList) {
nodeMap.put(n.id, n);
n.children = new ArrayList<>(); // 假设Node有children字段
}
for (Node n : flatList) {
if (n.parentId != null && nodeMap.containsKey(n.parentId)) {
nodeMap.get(n.parentId).children.add(n);
}
}
三、深度优先遍历提取层级路径
树建好之后，使用深度优先搜索（DFS）从每个根节点出发，维护一个当前路径栈。每进入一个节点，就把它的id压入路径，同时记录当前深度；离开时弹出。这样在访问任意节点时，我们都能拿到从根到它的完整链路。
路径可以以字符串形式拼接（如“1/2/3”），也可以保留为List以便灵活使用。关联issue只需在生成结果对象时，把当前节点的issue字段直接写入。下方代码展示如何输出包含层级路径与issue的结果列表。
3.1 路径提取与结果封装
class PathResult {
String id;
String path; // 例如 1/2/3
int depth;
String issue; // 关联原始分组字段
}
List<PathResult> results = new ArrayList<>();
List<String> stack = new ArrayList<>();
void dfs(Node n, int depth) {
stack.add(n.id);
String path = String.join("/", stack);
PathResult r = new PathResult();
r.id = n.id;
r.path = path;
r.depth = depth;
r.issue = n.issue; // 关联原始issue
results.add(r);
for (Node c : n.children) {
dfs(c, depth + 1);
}
stack.remove(stack.size() - 1);
}
// 从所有根节点启动
for (Node n : flatList) {
if (n.parentId == null) {
dfs(n, 1);
}
}
四、方案对比与注意事项
与数据库递归查询相比，内存树方案把计算压力从数据库转移到应用服务器，适合中等规模数据（几万条以内）且需要复用中间结果的场景。如果数据量极大，可以考虑分批构建或直接在SQL层解决。另一个常见误区是认为issue只能通过根节点继承，实际上原始分组字段应跟随记录本身，避免链路中某一层被重新赋值而导致统计偏差。
在输出时，如果业务要求“每个叶子节点关联其最早issue”，上述代码已经满足，因为issue来自节点自身。若需要“任意节点向上追溯根节点的issue”，只需在DFS时把根issue向下传递即可，改动极小。整体实现保持了扩展性与可读性，可以直接迁移到Python、JavaScript等语言。
| 实现方式 | 优点 | 缺点 |
|---|---|---|
| 内存树+DFS | 不依赖数据库特性，逻辑清晰 | 占用应用内存 |
| SQL递归 | 数据库优化，适合海量数据 | 方言差异大，难复用 |
五、总结
通过一次线性扫描建立id索引并挂载父子关系，再借助深度优先遍历回溯路径栈，我们就能在纯应用层完整地提取出父子层级路径，并且无缝关联原始的issue分组字段。该模式可直接用于工单溯源、部门层级展示、评论树展开等需求，开发与维护成本都较低。