简介：围绕 DataGridView 控件实现树形列表的 WinForms 示例包，面向需要在二维表格中呈现层次数据的 C# 开发者及 Visual Studio 2012 学习者，重点解决 DataGridView 原生不支持树形展开与折叠的问题。压缩包共 32 个文件、约 68KB，以 10 个 cs 源码为核心，辅以 config、resx、resources 等配置与界面资源，并含 sln、csproj 工程文件及编译输出，便于直接打开项目对照调试；源码中可见窗体设计、程序入口与自定义单元格绘制类，适合按模块阅读和二次开发。已有 1959 人学习，说明该实现思路在 WinForms 表格树形展示场景中具有一定参考价值。包内示例覆盖树形节点模型、数据绑定、列显示隐藏、CellClick 展开折叠、OnRowPrePaint 绘制缩进图标及单元格样式处理等关键环节，读者可据此理解 DataGridView 的扩展方式与事件驱动刷新逻辑，对列可见性、行绘制与刷新时机均有体现，可迁移到目录树、分组列表或分级报表等实际界面中。

1. 当需求方要求「点一下三角收起整棵子树」时，两个控件拼一起的方案就崩了

三年前接手一个资产管理模块，需求方给的参考截图是一张表格：部门、设备分类、具体资产层层缩进在同一列里，点前面的三角就收起整棵子树。听起来功能很小，实际上手才发现，DataGridView 控件显示树结构这件事，官方控件库压根没有现成方案——TreeView 只管层级不管列，DataGridView 只管列不管层级，硬拼两块控件的结果就是滚动条对不齐、选中行不同步、键盘上下键还得手动桥接。这套 DataGridView 树形列表方案，后来被复用到科目表、BOM 结构、组织架构好几个界面。这篇把数据模型、渲染、交互、回写到验收完整拆一遍，适合要交 WinForms 课设或毕设的同学，也适合在内部管理界面里塞一栏层级数据、又不想引第三方控件的开发者直接改。

2. 数据模型与控件选型：父子字段、层级深度与三条实现路线的取舍

动手写渲染之前，先花半天把模型定死，能省掉后面一半的返工。原因是树形表格的复杂度不在「画一个三角」，而在于「可见行集合」这个概念——界面上看到的行，是完整数据经过「祖先是否展开 + 是否命中筛选」两层过滤后的投影。模型设计对不上，后面每一次展开折叠都要重新查库。

2.1 邻接表够用，别一上来就上嵌套集

绝大多数业务场景的层级深度不会超过六级，节点数在几千到几万量级，用邻接表（每个节点存 parent_id）就够了。嵌套集、物化路径这些模型查询祖先更快，但每次增删节点都要批量改一堆记录的左右值或路径串，写入成本高，维护难度也上去了。我一般只在「层级读多写少 + 需要按子树范围查询」的场景才考虑物化路径。

建表时至少要有这几列，注意 parent_id 用 0 表示根节点而不是 NULL，能省掉大量IS NULL的判断分支：

CREATE TABLE t_node ( id INTEGER PRIMARY KEY AUTOINCREMENT, parent_id INTEGER NOT NULL DEFAULT 0, -- 0 表示根节点，不用 NULL 是为了方便等值比较 name TEXT NOT NULL, sort_no INTEGER NOT NULL DEFAULT 0, -- 同级排序号，允许重复，重复时用 id 兜底 node_type INTEGER NOT NULL DEFAULT 1, -- 节点类型，用于决定图标和允许的列编辑行为 row_version INTEGER NOT NULL DEFAULT 1, -- 乐观锁，回写时校验 deleted INTEGER NOT NULL DEFAULT 0 -- 软删除，树结构删除节点要连带子树，物理删容易出事 ); CREATE INDEX ix_node_parent ON t_node(parent_id, sort_no);

索引一定要建在(parent_id, sort_no)上。构建树的时候是按父节点分组再排序，这个复合索引正好覆盖，几万节点也能在几十毫秒内读完。sort_no允许重复这点很多人不习惯，但同级拖拽排序时如果强制唯一，每次移动都要批量重排一堆记录，反而容易出错；重复时用 id 做第二排序键，结果依然稳定。

2.2 三条实现路线的实际取舍

真正落地时有三条路可选，我把它们放在一起对比过，最后选了第二条：

双控件那条路我试过一版，最大的问题是纵向滚动不同步：TreeView 的滚动条位置和 DataGridView 的像素偏移不是线性对应关系，同步过去总差几个像素，长时间滚动后累积误差肉眼可见。另外用户按上下键的时候，两个控件的当前行会短暂不一致，截图给需求方看就是「有 bug」。所以这个方案最后定的是单表缩进列：层级只是第一列的表现形式，其余列照常绑定、照常编辑。

2.3 节点模型和运行时行的分离

数据库实体和界面行必须是两个类。实体对应表结构，运行时行额外携带层级深度、是否有子节点、是否展开这些纯界面状态，它们不该落库。混在一起的后果是每次刷新都要重新算一遍层级字段，还容易把脏状态写回数据库。

// 数据库实体，字段和表一一对应 public class NodeEntity { public int Id { get; set; } public int ParentId { get; set; } public string Name { get; set; } public int SortNo { get; set; } public int NodeType { get; set; } public int RowVersion { get; set; } } // 运行时行，多出的字段只在内存里存在 public class TreeRow { public int Id { get; set; } public int ParentId { get; set; } public string Name { get; set; } public int Level { get; set; } // 0 起，决定缩进多少像素 public bool HasChildren { get; set; } // 决定要不要画三角 public bool Expanded { get; set; } // 当前是否展开 }

Level和HasChildren是每次重建可见行时重新算的，不做持久化。Expanded也不存在行对象上，真正的数据源是一个「已折叠节点 id 集合」，行对象上的Expanded只是这个集合的快照。这样做的原因是行对象在每次展开、筛选、刷新时都会被整体重建，状态挂在行上必然丢。

3. 核心渲染：把层级压成缩进列、展开箭头和可见行集合

这一章是实现的主体。核心只有一句话：DataGridView 的 DataSource 里永远只放「当前应该看得见的行」，折叠的子树根本不出现在列表里。想清楚这句，后面所有逻辑都是它的推论。

3.1 一次递归把邻接表压成有序扁平表

装载过程是深度优先遍历：从根节点开始，同一层按sort_no排，遇到已折叠的节点就只加自己、不递归子节点。这里有两个必须处理的边界。

private readonly HashSet<int> _collapsed = new HashSet<int>(); // 已折叠的节点 id private List<NodeEntity> _allNodes; // 全量数据，装载时读一次 private List<TreeRow> BuildVisibleRows() { // 按父节点分组，组内先按排序号再按 id，保证结果稳定 var childrenOf = _allNodes .GroupBy(n => n.ParentId) .ToDictionary(g => g.Key, g => g.OrderBy(n => n.SortNo).ThenBy(n => n.Id).ToList()); var result = new List<TreeRow>(); var visited = new HashSet<int>(); // 防止脏数据成环导致无限递归 void Walk(int parentId, int level) { if (!childrenOf.TryGetValue(parentId, out var children)) return; foreach (var node in children) { if (!visited.Add(node.Id)) continue; // 已访问过，说明数据有环，直接跳过 var row = new TreeRow { Id = node.Id, ParentId = node.ParentId, Name = node.Name, Level = level, HasChildren = childrenOf.ContainsKey(node.Id), Expanded = !_collapsed.Contains(node.Id) }; result.Add(row); // 只有「有子节点」且「未折叠」才往下走，这是可见行集合的全部秘密 if (row.HasChildren && row.Expanded) Walk(node.Id, level + 1); } } Walk(0, 0); // 根节点约定 parent_id = 0 return result; }

visited这个集合看着多余，实际上是保命用的。业务系统里出现A 的父是 B、B 的父是 A这种环，来源五花八门：批量导入没校验、手工改库、并发拖拽时写了一半。没有这个集合，递归会直接栈溢出，而且报错位置和真正的问题源头隔了十万八千里，排查起来很痛苦。加上以后最坏情况是这部分数据不显示，程序照常跑。

HasChildren判断的是「有没有子节点」而不是「有没有可见的子节点」。哪怕子节点全被筛选掉了，三角也得画出来，否则用户会以为这节点是叶子。

3.2 缩进交给 CellFormatting，三角交给 CellPainting

这两个事件分工要清楚，混着用很容易出现「文字压着三角」或者「选中时三角被背景刷掉」。

缩进用CellFormatting设置单元格内边距，这是最省事的方式，文本绘制、选中高亮、自动换行全都自动跟着走：

private const int IndentPerLevel = 18; // 每级缩进像素 private const int ArrowSlot = 16; // 给三角预留的横向空间 private void Grid_CellFormatting(object sender, DataGridViewCellFormattingEventArgs e) { if (e.RowIndex < 0 || e.ColumnIndex != ColName) return; if (!(Grid.Rows[e.RowIndex].DataBoundItem is TreeRow row)) return; // 层级越深，左边距越大；额外加 ArrowSlot 保证文字不压住三角 e.CellStyle.Padding = new Padding(row.Level * IndentPerLevel + ArrowSlot, 0, 0, 0); }

三角必须自绘，因为 DataGridView 没有「每行显示不同图标」的原生列类型。绘制顺序是这套代码里最容易写错的地方：先画背景和选中态，再画三角，最后让控件画文字，三步的顺序不能换。

private void Grid_CellPainting(object sender, DataGridViewCellPaintingEventArgs e) { if (e.RowIndex < 0 || e.ColumnIndex != ColName) return; if (!(Grid.Rows[e.RowIndex].DataBoundItem is TreeRow row) || !row.HasChildren) return; // 第一步：背景、边框、选中高亮。漏掉 SelectionBackground 会导致选中行这里是白块 e.Paint(e.CellBounds, DataGridViewPaintParts.Background | DataGridViewPaintParts.Border | DataGridViewPaintParts.SelectionBackground); // 第二步：画三角。展开是朝下的实心三角，折叠是朝右的 int x = e.CellBounds.Left + row.Level * IndentPerLevel + 4; int cy = e.CellBounds.Top + e.CellBounds.Height / 2; Point[] points = row.Expanded ? new[] { new Point(x, cy - 4), new Point(x + 9, cy - 4), new Point(x + 4, cy + 4) } : new[] { new Point(x + 1, cy - 5), new Point(x + 8, cy), new Point(x + 1, cy + 5) }; using (var brush = new SolidBrush(Color.FromArgb(90, 90, 90))) e.Graphics.FillPolygon(brush, points); // 第三步：让控件自己画文字（会应用上一步设置的 Padding） e.Paint(e.CellBounds, DataGridViewPaintParts.ContentForeground); e.Handled = true; // 必须置 true，否则控件会再画一遍背景把三角盖掉 }

e.Handled = true这行漏掉的表现是三角一闪而过或者根本不出现，因为默认绘制会在你的绘制之后再刷一次背景。这是自绘单元格最常见的坑，第一次写基本都会踩。

3.3 命中判定：只有点在三角上才算展开

用户点三角是展开，点文字是选中，这两个行为要分开。如果整格都响应展开，用户想选这一行的时候会误触，体验很糟。

private void Grid_CellMouseClick(object sender, DataGridViewCellMouseEventArgs e) { if (e.Button != MouseButtons.Left || e.RowIndex < 0 || e.ColumnIndex != ColName) return; if (!(Grid.Rows[e.RowIndex].DataBoundItem is TreeRow row) || !row.HasChildren) return; // e.X 是相对单元格左上角的坐标，不受横向滚动影响 int arrowLeft = row.Level * IndentPerLevel + 2; int arrowRight = arrowLeft + 14; // 三角本身约 9 像素宽，左右各留 2~3 像素容错 if (e.X >= arrowLeft && e.X <= arrowRight) { ToggleExpand(row); return; // 命中三角就不再做选中处理，避免一次点击触发两个动作 } }

容错区间比三角实际宽度大一点，是因为鼠标点击本来就有几像素误差，卡得太死用户会觉得「这个三角时灵时不灵」。另外要注意e.X是相对单元格的坐标，不是相对整行的，也不是相对窗体的——拿Cursor.Position去算会引入滚动偏移，横滚之后位置全错。

展开动作本身只有三行，改集合、重建、恢复状态：

private void ToggleExpand(TreeRow row) { if (row.Expanded) _collapsed.Add(row.Id); // 原来是展开的，现在折叠 else _collapsed.Remove(row.Id); // 原来是折叠的，现在展开 ReloadPreservingState(row.Id); }

_collapsed存的是折叠集合而不是展开集合，好处是默认全部展开，新加进来的节点天然可见，不需要额外初始化。反过来存展开集合的话，每次新增节点都要手动补一条记录，容易漏。

3.4 重建之后，展开状态和选中行必须还原

ReloadPreservingState是这套方案里被调用频率最高的方法，也是最容易写漏的地方：每次给DataSource赋新列表，DataGridView 会把选中行、当前单元格、滚动位置全部重置到第一行，用户展开一个节点后被弹回顶部，这个体验是致命的。

private void ReloadPreservingState(int? keepSelectedId = null) { int scrollIndex = Grid.FirstDisplayedScrollingRowIndex; int selectedId = keepSelectedId ?? (Grid.CurrentRow?.DataBoundItem as TreeRow)?.Id ?? 0; var rows = BuildVisibleRows(); Grid.DataSource = new BindingList<TreeRow>(rows); // 恢复选中：按 id 找，不能按行号找，重建后行号全变了 if (selectedId != 0) { for (int i = 0; i < Grid.Rows.Count; i++) { if ((Grid.Rows[i].DataBoundItem as TreeRow)?.Id == selectedId) { Grid.CurrentCell = Grid.Rows[i].Cells[ColName]; break; } } } // 恢复滚动位置，注意夹住范围，否则行数变少会抛异常 if (scrollIndex >= 0 && scrollIndex < Grid.Rows.Count) Grid.FirstDisplayedScrollingRowIndex = scrollIndex; }

恢复选中一定按业务 id 找，不能记行号。展开一个节点后，它下面所有行的行号都往后挪了，按行号还原会选中错误的那一行——这种错误在测试时很容易被忽略，因为「选中的行还在可视区域内」，上线后用户才发现点开 A 结果选中了 B。

4. 交互与回写：展开状态、排序过滤、勾选联动和增量提交

树形表格真正难维护的部分不是绘制，是各种交互叠在一起之后的状态一致性。展开、筛选、勾选、排序、编辑，任意两个组合都会产生新的边界情况。这一章按「用户最常做的四个动作」逐个拆。

4.1 勾选联动：三态复选框比想象中好用

带权限分配、批量选择的界面基本都要勾选联动：勾父节点带上所有子孙，子孙全勾父节点变勾，部分勾变半选。很多人第一反应是自己画一个半选的方块，其实 DataGridView 的复选框列原生支持三态，只要把ThreeState打开，值按CheckState给就行。

// 初始化时 var checkCol = (DataGridViewCheckBoxCell)Grid.Columns[ColCheck]; checkCol.ThreeState = true; checkCol.TrueValue = CheckState.Checked; checkCol.FalseValue = CheckState.Unchecked; checkCol.IndeterminateValue = CheckState.Indeterminate;

联动逻辑要分清「向下传播」和「向上回算」两个方向，它们的规则不一样：

private void OnNodeCheckedChanged(TreeRow row, CheckState state) { // 向下：父节点勾选状态直接覆盖所有子孙，不管子孙原来是什么 if (state != CheckState.Indeterminate) ApplyToDescendants(row.Id, state == CheckState.Checked); // 向上：从父节点开始逐级回算，子节点全勾才算勾，全不勾才算不勾，其余都是半选 int parentId = row.ParentId; while (parentId != 0) { var siblings = _allNodes.Where(n => n.ParentId == parentId).ToList(); var states = siblings.Select(n => GetCheckState(n.Id)).ToList(); CheckState parentState; if (states.All(s => s == CheckState.Checked)) parentState = CheckState.Checked; else if (states.All(s => s == CheckState.Unchecked)) parentState = CheckState.Unchecked; else parentState = CheckState.Indeterminate; SetCheckState(parentId, parentState); parentId = _allNodes.FirstOrDefault(n => n.Id == parentId)?.ParentId ?? 0; } }

向下传播时要跳过半选状态，否则用户点一下半选的父节点，会把整棵子树刷成半选，看起来像卡死了。向上回算要一直走到根，不能只走一层，因为孙子的变化会影响儿子、儿子的变化又会反过来影响爷爷。

4.2 排序和筛选：别让子节点跑到父节点前面

DataGridView 默认点表头就排序，这在树形表格里是灾难：按名称排一下，子节点会跑到父节点上面去，缩进关系全乱。标准做法是把所有列的SortMode设成NotSortable，另外提供业务意义上的排序按钮。

foreach (DataGridViewColumn col in Grid.Columns) col.SortMode = DataGridViewColumnSortMode.NotSortable;

需要「按名称排序」时，正确做法是重排同级节点的sort_no，然后重建：

private void SortSiblingsByName(int parentId, bool ascending) { var siblings = _allNodes.Where(n => n.ParentId == parentId).ToList(); var ordered = ascending ? siblings.OrderBy(n => n.Name, StringComparer.CurrentCulture).ToList() : siblings.OrderByDescending(n => n.Name, StringComparer.CurrentCulture).ToList(); for (int i = 0; i < ordered.Count; i++) ordered[i].SortNo = i + 1; // 只重排同一层的兄弟节点 ReloadPreservingState(); }

关键是只动同级的sort_no，不能全局重排。全局重排会把不同父节点的排序号混在一起，父子关系还在但显示顺序莫名其妙。

筛选的逻辑反过来：命中关键字的节点要保留，它的所有祖先也要保留，否则命中的节点会因为父节点被过滤掉而根本不显示。实现上是从命中节点往上回溯，把整条祖先链加进白名单：

private HashSet<int> BuildFilterWhitelist(string keyword) { var map = _allNodes.ToDictionary(n => n.Id); var hits = _allNodes.Where(n => n.Name.IndexOf(keyword, StringComparison.OrdinalIgnoreCase) >= 0); var keep = new HashSet<int>(); foreach (var hit in hits) { var cur = hit; // 往上走到根，keep.Add 返回 false 说明这条链已处理过或者数据有环 while (cur != null && keep.Add(cur.Id)) cur = cur.ParentId == 0 ? null : map.TryGetValue(cur.ParentId, out var p) ? p : null; } return keep; }

keep.Add的返回值在这里起了双重作用：既能提前终止重复遍历，又天然挡住了环。回溯完把白名单交给BuildVisibleRows做二次过滤，命中节点可以额外标个高亮色，用户一眼能看出为什么这几行被留下了。

4.3 回写：只提交变化的两列，别整表覆盖

树形表格的编辑动作多数集中在「改名」和「拖动换父」，提交时如果整表DELETE再INSERT，并发场景下会丢数据，而且每次保存都要重写几万行，慢得离谱。正确的做法是记录最小变更集：只提交parent_id、sort_no、name这些真正变了的字段，并且带版本号校验。

public int SaveNodeChange(NodeEntity node) { const string sql = @" UPDATE t_node SET parent_id = @pid, sort_no = @sort, name = @name, row_version = row_version + 1 WHERE id = @id AND row_version = @ver AND deleted = 0"; using (var cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@pid", node.ParentId); cmd.Parameters.AddWithValue("@sort", node.SortNo); cmd.Parameters.AddWithValue("@name", node.Name); cmd.Parameters.AddWithValue("@id", node.Id); cmd.Parameters.AddWithValue("@ver", node.RowVersion); // 返回 0 说明有人在这次编辑期间改过这条记录，要提示用户刷新 return cmd.ExecuteNonQuery(); } }

参数化不只是防注入，更重要的是让数据库能复用执行计划。树形结构的保存往往是一次提交多条，复用计划能省下可观的解析开销。

拖拽改变父节点时，还有一个额外的校验不能省：目标父节点不能是自己的子孙。不做这个判断，用户手一抖就能把一棵子树拖进它自己的后代里，数据库里立刻出现环，下次加载直接触发前面说的栈溢出。

private bool IsDescendantOf(int nodeId, int candidateAncestorId) { // 从 nodeId 往上爬，看能不能遇到 candidateAncestorId var map = _allNodes.ToDictionary(n => n.Id); var cur = map.TryGetValue(nodeId, out var n) ? n : null; int guard = 0; // 防御性计数，脏数据成环时不会死循环 while (cur != null && guard++ < 10000) { if (cur.Id == candidateAncestorId) return true; cur = cur.ParentId == 0 ? null : (map.TryGetValue(cur.ParentId, out var p) ? p : null); } return false; }

5. 避坑排查：树形表格最容易翻车的五个点

下面这几条都是实际项目里出现过、并且排查花了不少时间的。按「现象 → 原因 → 解决」记下来，遇到类似症状可以对照着看。

5.1 三角点了没反应，或者要点偏一点才灵

现象是鼠标点在三角上毫无反应，点在旁边一点反而展开了，或者一行里只有最左边两三个像素能触发。

原因基本都在命中判定上。常见写法是用e.X直接和缩进量比较，但e.X是相对单元格的坐标，如果要减掉滚动偏移或者用Cursor.Position换算，横滚之后就会错位。另一种情况是容错区间设得太窄，三角本身 9 像素宽，判定区间只有 9 像素，用户点击难度很高。

解决办法是统一坐标系：只用e.X（相对单元格），判定区间左右各放宽 2~3 像素，并且把arrowLeft和缩进量的计算写成同一个表达式，别在绘制和命中的地方各写一份——两份代码不同步是这类问题的根源。

5.2 展开一个节点，列表弹回顶部、选中行也没了

现象是滚动到列表中间，点开一个节点，界面瞬间跳回第一行，之前选中的行变成别的行。

原因是每次重建都把DataSource整个赋新列表，DataGridView 认为数据全换了，选中和滚动状态全部重置。更隐蔽的情况是按行号恢复选中：展开后行号全变了，恢复出来的行看着「还在可视范围」，其实是错的。

解决办法是重建前先记下当前行的业务 id 和FirstDisplayedScrollingRowIndex，重建后按 id 找回选中，滚动位置要做范围夹取。注意滚动位置恢复要在选中恢复之后做，顺序反了会被选中行的自动滚动覆盖掉。

5.3 打开界面直接卡死或者栈溢出，日志里指向递归

现象是某些数据库加载时程序无响应，堆栈显示递归调用过深。

原因是数据里出现了父子成环。来源通常是批量导入没做校验、手工改库、或者拖拽换父时漏了「不能拖进自己后代」的判断。环一旦形成，深度优先遍历会永远走不完。

解决办法是遍历时带一个visited集合，遇到已访问节点直接跳过；同时在上游堵住入口，拖拽换父前做一次后代校验，导入时做一次全量环检测。库里的存量脏数据也要清，写个脚本从根开始遍历，遍历不到的节点就是环里的节点，单独列出来人工处理。

5.4 点一下表头排序，缩进关系全乱了

现象是用户习惯性点表头排序，排完之后子节点跑到父节点上面，缩进还在但层级看着不对。

原因是 DataGridView 的表头排序是对「当前可见行」整体排序，它不知道也不关心父子关系。排完之后虽然每一行的Level字段没变，但顺序变了，视觉上就是错乱的。

解决办法是把所有列的SortMode设成NotSortable，把排序能力收到业务按钮里，只重排同级兄弟节点的sort_no。如果确实需要「按某列全局排」这种能力，那就得换一个视图——切到不含层级的平铺模式，把树形视图和平铺视图做成两个可切换的页签，别在一张表上强行兼容两种排序语义。

5.5 几千行以上就卡顿，展开折叠有明显闪烁

现象是数据量到三五千行之后，每次展开都要顿一下，界面还会闪一下白。

原因有两层。第一层是每次重建都在新建BindingList、重新绑定DataSource，行对象全部重新创建，DataGridView 要重新测量所有行高。第二层是CellFormatting和CellPainting里做了重复计算，比如每次都FirstOrDefault查父节点，复杂度直接从 O(1) 变成 O(n)。

解决办法分三档：数据量在五千行以内，把查找提前做成Dictionary缓存，然后开双缓冲（继承 DataGridView 加DoubleBuffered = true，或者设ControlStyles.OptimizedDoubleBuffer）基本够用；数据量上万，改成只重建受影响的子树，别整表重绑；数据量再往上，只能上虚拟模式，DataSource不存行，CellValueNeeded按需取值，这时候缩进和三角全部在CellPainting里算，命中判定也要改成按需构建索引。

6. 验收与演示：怎么证明这棵树删不坏、点不乱、跑得动

交付前我会跑一遍固定清单，这套清单是从几次返工里总结出来的，照着走能挡住九成的现场问题。

第 5 条和第 6 条最容易被跳过，但恰恰是上线后最容易出事的。拖拽成环的问题一旦漏到生产环境，整个界面会打不开，只能靠改库救场；版本冲突不处理则是静默覆盖，用户改的东西莫名其妙消失，事后根本查不出来。

演示的时候，我会按「先展示正常路径，再主动制造一个边界，最后给出防御效果」这个顺序走。正常路径是展开三层、改个名字、保存、重新加载看结果；制造边界是搜一个深层叶子节点，让大家看到祖先链自动展开；防御效果是当场试着把父节点拖进自己的子节点，看提示弹出来。这个顺序比从头到尾点一遍功能更有说服力，因为它回答了「出错的时候会怎样」这个所有人都会关心但很少有人在演示里提的问题。

从那以后我每次做层级类界面，都强制先把「环检测」和「状态还原」这两件事写完再动渲染代码，哪怕界面还是白板一块。这两块补在最后，代价往往是推倒重写。希望这套结构能帮到你，把你手上那张表格一次做对。

本文还有配套的精品资源，点击获取