记一次生产问题的排查，页面直接崩掉，让我领略了算法的重要性

前段时间，客户反馈，有个PC端的功能页面，一点开就卡死，通过查看网络请求，发现有个部门组织架构树的请求数据有点大，共有两万条数据,1.57M。刚开始我以为是表单中的部门选择框渲染的时候，一次性渲染的dom节点过多，把页面内存撑爆了。于是我把项目中使用的antd3的TreeSelect组件，升级到具有无限滚动加载功能的antd5版本，始终只渲染10条数据，按理说页面卡死的问题应该就消失了。结果页面操作几次之后，页面仍旧百分之百会崩掉， 页面卡死问题并未彻底解决。

于是我沉下心来，把出问题的页面的逻辑从头到尾看了一遍，发现有一处采用递归方式查找某个部门id在不在部门树之中的逻辑，可能存在性能问题。没优化之前的写法是这样的：

const findTreeItem = (data, id) => {
  for (let i = 0,len=data.length; i < len; i++) {
    let item = data[i];
    if (item.id === id) {
      return true;
    } else {
      if (item.children) {
        if (findTreeItem(item.children, id)) {
          return true;
        }
      }
    }
  }
};
const isInclude = findTreeItem(treeData,deptId);

这种写法的缺点是，当树的层级很深时，可能会引起暴栈。让我们分析一下这种递归算法的空间复杂度。假设要判断id="1-1-1-0"是否存在于treeData中

cons