响应式系统处理递归树形结构的核心是让数据变化可追踪、计算可中断、渲染可按需；应避免全量响应式代理，采用浅层响应式、分阶段加载、虚拟滚动、深度限制搜索、预建索引及服务端协同等优化策略。
响应式系统处理递归树形结构，核心不是“强行渲染整棵树”，而是让数据变化可追踪、计算可中断、渲染可按需。面对大规模组织架构（比如1200+节点甚至百万级），卡顿根源往往不在数据本身，而在默认的全量响应式绑定与同步渲染机制上。
避免全量响应式代理导致的性能雪崩
Vue 或 React 默认会对整个树对象做响应式处理（如 reactive(tree) 或 useState(tree)）。当树深度大、子节点多时，每个节点的 getter/setter 都会注册依赖，造成内存暴涨和触发开销剧增。尤其在频繁展开/收起、搜索过滤时，computed 会反复执行完整递归过滤——哪怕只改了一个字段，也可能重跑上千次判断。
建议做法：
- 对原始树数据做浅层响应式：只代理顶层属性（如 ref({ nodes: [], version: 1 })），子节点用普通对象或 markRaw 跳过深层代理
- 搜索、过滤等派生逻辑用 computed 封装，但内部 filterTree 函数保持纯函数特性，不修改原数据
- 关键词为空或长度＜2时，直接返回空数组或原引用，跳过递归入口
分阶段加载 + 虚拟滚动，切断“一次性渲染”惯性
首次加载1200个节点耗时6.8秒，本质是浏览器主线程被阻塞。解决思路是把“渲染”拆成“数据获取→结构构建→可视区呈现”三步，且每步可控。
可行组合：
- 懒加载 + 展开即拉：初始只加载一级部门；点击展开二级时，才请求该分支的子节点（带缓存标识，避免重复拉）
- 虚拟滚动容器：用 vue-virtual-scroller 或自实现占位方案，只渲染当前可视区域±5个节点，其余用 height × count 占位
- requestIdleCallback 分片处理：若必须预加载全部节点，用它切分递归构建任务，在浏览器空闲时段逐步注入
保留层级语义的同时降低计算负担
模糊搜索要求“匹配叶子也要带出所有祖先”，这容易诱发深度递归。但实际业务中，90%的搜索集中在前3级（如部门名、负责人姓名），无需遍历到底。
优化关键点：
- 给 filterTree 加深度限制（如 maxDepth: 4），超过则跳过子树，同时标记 “…（更多）” 提示用户可展开查看
- 预建扁平索引：在数据加载后，用一次遍历生成 { keyword → [nodeId, nodeId] } 映射表，搜索时查表再反查路径，O(1) 定位 + O(d) 回溯
- 高亮不改原始数据：模板中用 v-html 或计算属性动态包裹关键词，避免为每个节点新增 highlight 字段引发响应式扩散
服务端协同减少前端压力
当组织架构达百万级（如企业微信私有化场景），纯前端优化已达极限。此时需前后端协同：
- 接口支持 path 查询：如 /dept?path=1001/2005/3012，服务端直接返回该路径下所有节点，省去前端逐层拼接
- 搜索接口返回已裁剪的“最小路径树”：服务端完成递归过滤与祖先补全，前端只做渲染，不碰逻辑
- DB 层启用 WAL 模式 + 读写分离：避免加载部门详情时被全量更新任务阻塞（实测可将二级部门打开时间从60s+压至800ms内）
