VSCode TreeView自定义必须实现TreeDataProvider，核心是getChildren（返回Promise<TreeItem[]>）和getTreeItem（返回TreeItem实例），缺一不可；直接return[]会阻断懒加载，须用Promise.resolve([])保留展开能力。
TreeDataProvider 的 getChildren 为什么不能直接 return []？
因为返回空数组会阻断懒加载链路——VSCode 遇到 getChildren 同步返回 []，就默认该节点无子项、不可展开，后续再调用 refresh() 也不会重新触发 getChildren。真正的懒加载必须让首次调用返回一个 pending Promise，哪怕只是 Promise.resolve([])，才能保留“点击后才加载”的行为。
常见错误写法：getChildren() { return []; } → 节点永远灰显、无法展开
正确做法应区分状态：
- 未加载过：返回
Promise.resolve([])，同时异步发起真实数据请求 - 已加载但为空：仍返回
Promise.resolve([])，但可加element.collapsibleState = vscode.TreeItemCollapsibleState.None - 加载中：设
collapsibleState = vscode.TreeItemCollapsibleState.Loading，UI 显示旋转图标
如何避免频繁刷新导致的树视图抖动？
每次调用 refresh() 都会触发整棵树重绘，如果在搜索、过滤或轮询场景下高频触发，用户会明显感知到闪烁或卡顿。关键不是少调用，而是精准通知——只刷新变动的分支，而非整个树。
VSCode 1.85+ 支持局部刷新：fire(element)（传入具体节点）比 fire(undefined) 更高效。但注意：element 必须是之前 getTreeItem 返回过的同一实例，否则无效。
实操建议：
- 缓存每个节点的
TreeItem实例，不要每次getTreeItem都新建对象 - 数据变更时，只对受影响的父节点调用
_onDidChangeTreeData.fire(parentElement) - 若需刷新叶子节点，先向上找到最近的、已展开的父节点再 fire
- 避免在
getChildren内部直接调用refresh()，容易形成递归调用
为什么 TreeItem.label 更新了但视图没变？
VSCode 树视图不监听 TreeItem 属性变化，它只认“数据源整体刷新”或“指定节点 fire”。即使你修改了某个 TreeItem.label 的值，只要没触发 onDidChangeTreeData 事件，UI 就不会更新。
典型陷阱：
- 把
TreeItem当作响应式对象直接改属性（如item.label = 'new'）→ 无效 - 在
getTreeItem中动态计算 label，但没配合refresh()→ label 不更新
解决方式只有两种：
- 调用
_onDidChangeTreeData.fire(element)，且element是你修改过的那个TreeItem实例 - 或在
getTreeItem中始终返回新实例，并确保 label 值来自最新数据源（适合纯静态 label）
后者更轻量，但要求 label 计算无副作用；前者更灵活，适合 label 需实时反映后端状态的场景。
懒加载 + 搜索过滤时的性能断点在哪？
当用户输入关键词，你一边过滤已有节点、一边对匹配节点触发 getChildren，很容易在深层嵌套结构中引发瀑布式请求，瞬间堆积数十个 Promise，主线程被拖慢，UI 响应滞后。
根本问题不在网络或磁盘，而在并发控制缺失。VSCode 扩展运行在单线程中，大量并行 Promise 会挤占渲染时机。
推荐做法：
- 限制最大并发请求数（如 3～5），用
p-limit或手写队列控制 - 对搜索结果做节流：输入停顿 300ms 后再执行过滤 + 加载，避免每敲一个字都重算
- 过滤时优先展示已加载的节点，未加载的显示“（点击展开）”占位，而非强行触发加载
- 若搜索命中深度 > 3 层，直接跳过子节点加载，等用户手动点击再展开
最易被忽略的是：搜索本身不该触发任何 getChildren，它只应筛选内存中已存在的节点。加载和过滤必须解耦。
