《JS列表转树实操指南》

JS列表转树实操指南｜递归与Map最优解详解

在前端开发中，扁平列表转树形结构是极为常见的基础操作。后台接口返回的数据往往是扁平的（通过parentId关联父子关系），而前端渲染层级组件（如菜单、分类、省市区选择器）时，需要将其转换为嵌套的树形结构。

本文将从零到一，拆解列表转树的两种核心实现方案------递归法（易上手）和Map优化法（高性能），补充实操细节、代码注释和场景应用，帮你快速掌握两种解法的核心逻辑，轻松应对开发中的各类层级数据处理需求。

一、什么是列表转树？核心场景

列表转树，本质是将「扁平结构数据」（通过parentId字段关联父子节点），转换为「层级嵌套结构数据」（通过children字段存储子节点），是前端处理层级关系数据的核心技巧。

1. 输入输出示例（开发实操标准格式）

后台返回的扁平列表（最常见格式）：

// 核心关联字段：id（节点唯一标识）、parentId（父节点id）
const flatList = [
  { id: 1, parentId: 0, name: '一级菜单A' },
  { id: 2, parentId: 1, name: '二级菜单A-1' },
  { id: 3, parentId: 1, name: '二级菜单A-2' },
  { id: 4, parentId: 2, name: '三级菜单A-1-1' },
  { id: 5, parentId: 0, name: '一级菜单B' },
];

前端渲染所需的树形结构：

[
  {
    id: 1,
    parentId: 0,
    name: '一级菜单A',
    children: [
      {
        id: 2,
        parentId: 1,
        name: '二级菜单A-1',
        children: [
          { id: 4, parentId: 2, name: '三级菜单A-1-1', children: [] }
        ]
      },
      { id: 3, parentId: 1, name: '二级菜单A-2', children: [] }
    ]
  },
  { id: 5, parentId: 0, name: '一级菜单B', children: [] }
]

2. 核心约定（开发通用规范）

• 根节点的parentId固定为0（行业通用约定，若后台返回为null或undefined，可微调判断条件）；
• 每个节点必须拥有唯一id，避免父子关联错乱，确保层级结构正确；
• 转换过程中不修改原始扁平列表（遵循数据不可变性，避免影响其他依赖该列表的业务逻辑）；
• 无子节点的节点，children字段设为空数组（统一数据格式，便于前端组件统一渲染，避免报错）。

二、解法一：递归法（易上手，适合中小型列表）

递归法是最直观、最易理解和编写的解法，核心思路是「逐层查找并嵌套子节点」：从根节点（parentId=0）开始，先筛选出其直接子节点，再对每个子节点递归执行相同操作，查找其下一级子节点，直到某个节点无子节点，递归自动终止。

1. 完整可运行代码（极简实操版）

/**
 * 递归实现列表转树
 * @param {Array} list - 待转换的扁平列表数据
 * @param {Number} parentId - 父节点id，默认0（根节点父id）
 * @returns {Array} 转换后的树形结构数组
 */
function listToTree(list, parentId = 0) {
  // 1. 筛选当前父节点的所有直接子节点
  const directChildren = list.filter(item => item.parentId === parentId);
  
  // 2. 遍历每个直接子节点，递归查找其下一级子节点，补充children属性
  return directChildren.map(child => ({
    ...child, // 复制原节点所有属性，避免修改原始列表数据
    children: listToTree(list, child.id) // 递归：以当前子节点id为父id，查找其下一级子节点
  }));
}

2. 核心逻辑拆解（通俗好懂）

很多人觉得递归"难理解"，其实只要抓住「核心逻辑+终止条件」，就能轻松掌握：

• 核心逻辑：当前节点的children数组，等于「所有parentId等于当前节点id」的子节点集合，通过递归调用自身实现层级嵌套；
• 终止条件：当某个节点没有子节点时，filter方法会返回空数组，map方法也会返回空数组，此时children为空，递归自动停止，无需手动判断终止。

3. 实操注意事项（避坑重点）

• 避免修改原始数据：必须用扩展运算符...child复制原节点，再补充children属性，若直接修改child（如child.children = ...），会污染原始扁平列表，影响其他业务逻辑；
• 不传入列表副本：递归时直接传入原始list即可，无需用list.slice()等方法创建副本，否则每次递归都会生成新数组，浪费内存；
• 兼容异常数据：若列表中存在parentId无效（无对应父节点）的节点，该节点会被自动过滤，不会影响整体树形结构生成。

4. 性能特点（适配场景说明）

• 时间复杂度：O(n²) ------ 每次递归都会遍历整个列表（filter操作），若列表长度为n，最坏情况下（树退化为单链表），会递归n次，总遍历次数为n×n；
• 空间复杂度：O(n) ------ 递归调用栈的深度最多为树的层级（最坏n层），同时生成的树形结构包含n个节点，内存开销可控；
• 适配场景：适合中小型扁平列表（数据量n<1000），如简单菜单、小型分类，代码简洁、易调试，开发效率高。

三、解法二：Map优化法（高性能，生产环境首选）

递归法的核心短板是「重复遍历列表」，导致数据量大时性能下降。Map优化法的核心思路是「空间换时间」：利用ES6 Map数据结构，先构建「节点id→节点对象」的映射表，实现"O(1)快速查找父节点"，将时间复杂度从O(n²)优化到O(n)，是生产环境处理大数据量列表的首选解法。

1. 完整可运行代码（生产级健壮版）

/**
 * Map优化版列表转树（高性能，生产级）
 * @param {Array} list - 待转换的扁平列表数据
 * @param {Number} rootParentId - 根节点的parentId，默认0
 * @returns {Array} 转换后的树形结构数组
 */
function listToTreeOptimize(list, rootParentId = 0) {
  // 1. 创建Map映射表：存储id→节点对象，实现O(1)快速查找父节点
  const nodeMap = new Map();
  // 2. 存储最终转换后的树形结构（仅存放根节点，子节点通过children嵌套）
  const tree = [];

  // 第一步：遍历列表，构建Map映射，为每个节点初始化空children数组
  list.forEach(item => {
    // 复制原节点，初始化children为空数组，避免修改原始数据
    nodeMap.set(item.id, { ...item, children: [] });
  });

  // 第二步：再次遍历列表，将每个节点挂载到其对应父节点的children中
  list.forEach(item => {
    const currentNode = nodeMap.get(item.id); // 当前节点（从Map中快速获取）
    const parentNode = nodeMap.get(item.parentId); // 父节点（O(1)快速查找）

    if (item.parentId === rootParentId) {
      // 根节点：直接加入树形结构的根数组
      tree.push(currentNode);
    } else if (parentNode) {
      // 子节点：挂载到其父节点的children数组中（防御父节点不存在的异常）
      parentNode.children.push(currentNode);
    }
  });

  return tree;
}

2. 核心优化点（高性能原因）

对比递归法，Map优化法的核心优势是「减少重复遍历」，重点优化了两点：

• Map映射表的作用：将"每次递归遍历整个列表找父节点"（O(n)耗时），优化为"通过Map.get(parentId)快速查找父节点"（O(1)耗时），彻底解决重复遍历的问题；
• 两次遍历的意义：第一次遍历仅用于构建Map映射并初始化children数组，第二次遍历仅用于挂载子节点，逻辑清晰，且能完美处理"子节点在父节点之前出现"的异常情况（如列表中id=4的节点在id=2的节点之前）。

3. Map vs 普通对象（实操选择指南）

开发中，很多人会用普通对象（{}）代替Map构建映射表，两者各有优劣，可根据场景灵活选择，具体对比如下：

对比项	普通对象（{}）	ES6 Map
键的类型	仅支持字符串、数字（数字会自动转为字符串）	支持任意类型（数字、字符串、对象等），更灵活
查找效率	普通场景可用，当键的数量过多时，效率会明显下降	查找、插入、删除效率始终为O(1)，适合频繁操作、大数据量
安全性	可能被原型链污染（如键名为__proto__时，会修改对象原型）	无原型链相关问题，数据存储更安全，生产级开发首选

4. 性能特点（生产环境适配）

• 时间复杂度：O(n) ------ 仅对扁平列表遍历两次（两次forEach），Map的get、set操作均为O(1)，总耗时与列表长度n成正比，效率最优；
• 空间复杂度：O(n) ------ Map映射表存储n个节点，最终生成的树形结构也包含n个节点，空间开销可控，是"空间换时间"的合理取舍；
• 适配场景：适合大数据量、深层级的扁平列表（如省市区三级数据、大型后台菜单），无递归栈溢出风险，性能稳定。

四、两种解法对比（开发选型指南）

开发中无需盲目追求"高性能"，应根据列表数据量、层级深度选择合适的解法，以下对比可直接作为选型参考：

解法	时间复杂度	空间复杂度	适配场景	开发优势
递归法	O(n²)	O(n)	中小型列表（n<1000）、层级浅	代码简洁、易理解、开发调试快
Map优化法	O(n)	O(n)	大数据量、深层级列表、生产环境	性能最优、无栈溢出、安全性高

5、总结（快速上手指南）

掌握列表转树的核心，关键是「理解parentId与children的关联关系」，两种解法可按需选择，无需死记硬背：

• 快速开发、数据量小时，选递归法：代码简洁、易上手，调试方便，适合中小型列表；
• 生产环境、数据量大时，选Map优化法：性能最优、无栈溢出风险，安全性高，适配各类复杂场景；
• 核心原则：始终遵循「数据不可变性」，避免修改原始列表，同时做好异常数据防御，确保代码健壮性。