小程序页面渲染树形结构数据时，常见做法是把节点通过递归模板一次性铺开。节点少时体验尚可，但树形数据一旦膨胀到几百上千条，setData 的数据量、节点创建数量以及滚动时的重排成本都会快速上升。虚拟列表的思路是只渲染可视区域内的节点，其余位置用占位高度替代，能把页面节点数量控制在一个稳定范围。本文不涉及具体业务组件库，而是拆解一个可复用的树形虚拟列表组件实现，覆盖数据拍平、可视区计算、高度缓存、展开折叠和滚动优化。
一、把树形结构拍平成线性渲染列表
树形数据本身是嵌套的，而虚拟列表需要知道每一项在滚动方向上的位置。直接对嵌套结构做可视区计算会很复杂，因此第一步是把它转换为一个线性数组。这个数组中的每一项除了保留原始节点信息，还需要记录层级深度、父节点标识、展开状态以及是否存在子节点。层级深度用于控制缩进，展开状态决定其子节点是否参与后续拍平。父节点标识在定位和更新时很有用。
拍平操作可以基于递归实现。遍历节点时先压入当前节点，再判断如果该节点为展开状态且有子节点，就递归处理子节点并把深度加一。如果遇到折叠状态，就跳过它下面的所有子节点。这样生成的数组顺序刚好符合树形数据从上到下的展示顺序，后续根据滚动偏移量计算可见区时，只需要遍历这个线性结构即可。要注意的是，原始树中每个节点的 expanded 字段最好独立保存，不能直接修改原始业务数据，否则容易在展开收起时丢失初始状态。
function flattenTree(nodes, depth = 0, parentId = null, result = []) {
nodes.forEach((node) => {
const flatNode = {
id: node.id,
name: node.name,
depth,
parentId,
hasChildren: !!(node.children && node.children.length),
expanded: node.expanded !== false
};
result.push(flatNode);
if (flatNode.expanded && node.children) {
flattenTree(node.children, depth + 1, node.id, result);
}
});
return result;
}
实际项目中如果树数据很大，递归深度过深可能带来调用栈压力。小程序 JavaScript 环境对递归深度有限制，当层级特别多时，可以改成显式栈迭代。核心逻辑不变，只是把函数调用换成数组模拟的栈，避免极端数据下栈溢出。另外，这个拍平结果应该放在组件内部维护，不要每次滚动都重新生成，只在初始化或展开状态变化时重新计算。
二、可视区切片与高度缓存
得到线性列表后，下一步是根据当前滚动位置计算哪些节点需要渲染。如果一个节点的行高固定，计算会非常简单，但树形结构里节点内容可能因为层级、备注信息、图片等元素变化，高度不一定一致。为了兼容这种场景，组件需要维护一个高度缓存。每个节点第一次渲染后，通过 wx.createSelectorQuery 或节点布局信息记录它的实际高度，后续可视区计算可以直接从缓存读取，减少实时测量。
计算可视范围时，需要累加每个节点的高度得到它在总滚动高度中的偏移量。总高度是所有拍平节点高度之和，滚动位置 scrollTop 代表已经滚过的距离。通过二分查找或者顺序累加，可以很快找到第一个偏移量超过 scrollTop 的节点作为起始索引，再继续累加直到偏移量超过 scrollTop + viewportHeight，得到结束索引。这两个索引之间的节点就是需要渲染的 visibleNodes，其余节点用顶部和底部占位高度替代。
function computeVisibleRange(flatList, heights, scrollTop, viewportHeight) {
const positions = [];
let offset = 0;
for (let i = 0; i < flatList.length; i++) {
positions.push(offset);
offset += heights[flatList[i].id] || 48;
}
const totalHeight = offset;
let start = 0;
let end = flatList.length;
for (let i = 0; i < positions.length; i++) {
if (positions[i] + (heights[flatList[i].id] || 48) > scrollTop) {
start = Math.max(0, i - 3);
break;
}
}
for (let i = start; i < positions.length; i++) {
if (positions[i] >= scrollTop + viewportHeight) {
end = Math.min(flatList.length, i + 3);
break;
}
}
return { start, end, totalHeight };
}
上面的代码使用了 48 作为默认高度，当节点高度尚未缓存时保证计算可以推进。给起始索引和结束索引各增加 3 个缓冲项，是为了用户快速滚动时能提前多渲染几项，减少白屏概率。高度缓存更新后，需要重新计算总高度，并把新的偏移量写入每个可见节点的 style 中。小程序里直接用绝对定位和 top 值来放置节点，可以让滚动容器的高度由外部占位节点撑开，内部节点不参与文档流。
高度测量涉及 DOM 查询，效率不高，因此不能对每个节点频繁测量。推荐的做法是初次渲染后只测量可视区域内新增的节点，测量完成后缓存并触发一次局部的 setData。如果节点高度变动是用户操作引起的，比如展开一个长列表子节点，这时需要显式更新对应节点的高度缓存，并重置后续所有节点的偏移量。
三、展开折叠与滚动节流：避免全量更新
树形组件中，用户点击节点时需要展开或收起子节点。最简单的做法是直接修改该节点的 expanded 状态，然后重新执行一次拍平，生成新的线性数组。这个操作本身不复杂，但要注意两点：一是展开或收起后总高度会变化，如果之前用户停留在较深位置，可能会产生跳动；二是不要因为一次点击就把整个树重新 setData，尽量只更新变化的部分。
为了减少跳动，可以在更新前记录当前滚动位置和第一个可见节点的偏移量。重新拍平后，根据目标节点的偏移变化调整 scrollTop，再把新的 flatList 传给组件。实际写组件时，我会把点击节点的 id 和操作类型通过事件抛给外层，外层维护树数据和展开状态，再调用组件提供的 updateTree 方法刷新。
滚动事件是高频率触发的回调，bindscroll 每次滚动都可能连续调用几十次。如果直接在回调里执行 computeVisibleRange 并 setData，很容易把帧时间打满。需要做节流或配合 wx.nextTick、requestAnimationFrame 这类机制。小程序端可以使用一个标志位，滚动回调里只保存最新的 scrollTop，等到下一帧再统一计算并更新。
handleScroll(e) {
this.scrollTop = e.detail.scrollTop;
if (this.pending) {
return;
}
this.pending = true;
setTimeout(() => {
this.pending = false;
this.updateVisibleNodes();
}, 16);
}
还有一种优化是使用 WXS 响应事件，把滚动状态的计算放在视图层处理，减少逻辑层与视图层的通信成本。不过 WXS 适合处理非常轻量的计算，如果涉及复杂的高度缓存和树结构调整，维护成本会更高。组件规模不大时，用 16ms 节流已经足够让滚动帧率稳定在 50 帧以上。
除了滚动节流，setData 的颗粒度也要控制。不要把整个 flatList 或者全部节点高度塞进 setData，每次只更新 visibleNodes 和 totalHeight 两个字段。小程序数据传输到视图层需要序列化，数据量越大越慢。可视区节点一般控制在 20 到 40 个，这个数量级下 setData 的开销可以忽略。
四、WXML 模板与性能对比
模板部分需要配合前面的线性数据和绝对定位。外层的 <scroll-view> 设置固定高度并绑定滚动事件，内部放一个占位 <view>，高度为 totalHeight。每个可见节点用绝对定位放在占位容器内，top 值直接来自计算好的偏移量。节点左侧缩进通过 style 绑定 depth 乘以一个固定缩进值实现。
<scroll-view class="tree-scroll" scroll-y="true" bindscroll="handleScroll" style="height: 100vh;">
<view style="height: {{totalHeight}}px; position: relative; width: 100%;">
<view
wx:for="{{visibleNodes}}"
wx:key="id"
class="tree-node"
style="top: {{item.offset}}px; height: {{item.height}}px; padding-left: {{item.depth * 24}}px;"
data-id="{{item.id}}"
bindtap="handleToggle"
>
<text class="node-name">{{item.name}}</text>
</view>
</view>
</scroll-view>
这套方案在两千个树节点、每屏显示约 15 个节点的测试中，页面初始节点数量从两千多个降到 30 个左右，setData 传输的数据量也下降了一个数量级。滚动流畅度有明显改善，尤其是低端安卓机上，全量渲染时滚动帧率会掉到 20 帧以下，虚拟列表可以维持在 55 帧上下。展开或收起深层节点时，因为只重新拍平并更新可见范围，接口响应也能保持在毫秒级。
有几个常见误区需要避开。第一是以为虚拟列表可以减少数据总量，它并不减少业务数据，只是减少渲染节点，内存中的数据仍然完整存在。第二是忽略节点 key 的稳定性，如果使用数组索引作为 wx:key，在展开收起导致线性数组顺序变化时，小程序会错误复用节点状态。第三是过度测量高度，每次展开都全量测量所有节点会明显拖慢交互，应该只测量新增或变化节点。第四是不给滚动容器固定高度，虚拟列表依赖视窗高度和滚动位置，容器高度不确定就无法计算可见区。
总体而言，树形虚拟列表组件的开发重点在于线性化数据、高度缓存和更新粒度控制。它比普通列表虚拟化更复杂，但实现后对树形业务页面的性能提升非常直接。组件代码可以封装成独立模块，在组织架构、评论回复、地区选择等场景复用，后续还可以扩展异步加载、搜索定位和多选等功能。