在前端开发的日常里咱们总是免不了要和数据打交道。说实话，处理数据这事儿，听起来简单，真要Zuo好了可没那么容易。你想想kan，Zui原始的时候，我们是怎么遍历一个数组的？大概hen多人脑子里dou会蹦出那个经典的 for 循环写法吧。

for  {
  nums = i + 1;
}
var evens = nums.filter;
document.write;
// ... 后续还有一堆操作

这种写法虽然直观，但一旦数据结构变得复杂，或者数据来源变了代码维护起来简直让人头大。这就引出了咱们今天要聊的主角——迭代器模式。这玩意儿在JavaScript里可是个重头戏，搞懂了它，你对hen多语法的理解dou会豁然开朗。

到底什么是迭代器模式？

咱们先别急着背定义，先来聊聊它的核心思想。其实它和我们以前接触过的不少设计模式一样，终极目标就一个：Zui大程度地降低内部变化对外部代码的干扰。

试想一下Ru果你手里有一堆杂乱的数据，有的存在数组里有的存在树结构里还有的可Neng是在某种特殊的链表里。Ru果没有统一的标准，你每换一种数据结构，就得重写一遍遍历逻辑。这谁受得了？

迭代器模式的定义听起来有点高大上：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。

咱们把它翻译成大白话，其实就是：别管数据里面长什么样，我只负责给你提供一个“下一个”的按钮，你按一下我就给你吐出一个数据，直到全部吐完为止。

它的重点不在于“存数据”，而在于把遍历这件事标准化。这样一来使用者根本不需要知道数据是咋存的，只要会用这个“标准接口”就行了。

JavaScript里的“协议”游戏

在JavaScript的世界里这个模式是通过一套特定的协议来实现的。这里有两个概念特别容易混淆，咱们得掰扯清楚：iterator 和 iterable。

1. 迭代器对象

所谓的 iterator，指的就是那个具体的干活对象。它Zui起码得具备一个 next 方法。你每调用一次这个方法，它就乖乖地返回一个对象给你。这个对象里通常包含两个属性：

value当前遍历到的值。

done一个布尔值，告诉你遍历结束了没。

咱们来kan个Zui简单的例子，用原生代码模拟一下这个过程：

const arr = ;
// 获取迭代器对象
const iterator = arr;
console.log); // { value: 'Vue', done: false }
console.log); // { value: 'React', done: false }
console.log); // { value: 'Svelte', done: false }
console.log); // { value: undefined, done: true }

kan到没？这就是Zui底层的逻辑。本质上就是从一个对象里拿到了一个“指针”，然后一步步往后挪。

2. 可迭代对象

那 iterable 又是啥呢？它指的是可迭代对象。简单来说就是这个对象比较“懂事”，它实现了 这个方法。当你对它进行遍历操作时JS引擎就会自动去找这个方法，拿到对应的迭代器，然后帮你干活。

像 ArrayMapSetString 这些内置对象，天生就是可迭代对象。这也是为什么我们Ke以这么写代码：

const set = new Set;
for  {
  console.log;
}
console.log; // 
运算符
console.log); // 转数组

也就是说for...of 运算符 ...Array.from 这些kan起来hen酷的语法，背后其实dou是建立在迭代器这套机制之上的。它们之所以Neng通吃这么多数据结构，全靠这个统一的协议。

实战演练：搞定复杂的树形菜单

光说不练假把式。咱们来kan一个前端开发里特别常见的场景：树形菜单遍历。

比如后台管理系统左侧那一坨菜单，数据结构通常是这样的：

const menuTree = 
  },
  {
    title: '系统设置',
    hidden: false
  }
];

现在的需求是：把所有可见的菜单依次渲染出来。注意，是“可见”的，那些标记了 hidden: true 的得跳过。

Ru果不使用迭代器模式...

要是每次dou在业务代码里手写 for 循环、递归、条件判断，那代码不仅不好复用，后面数据结构一变，遍历逻辑也得跟着改。大概率你会写出一个递归函数，像这样：

function collectVisibleMenus {
  // 先遍历当前层
  nodes.forEach(node => {
    if  {
      result.push;
    }
    // 再递归遍历子节点
    if  {
      collectVisibleMenus;
    }
  });
  return result;
}
const visibleMenus = collectVisibleMenus;
visibleMenus.forEach(menu => {
  renderMenu;
});

这样写当然Neng跑，但你hen快就会发现几个问题：

逻辑耦合：业务代码和遍历逻辑混在一起。

内存占用：Ru果菜单特别多，你得先生成一个巨大的 visibleMenus 数组，这多占内存啊。

灵活性差：Ru果明天需求变了要改成广度优先遍历，那你是不是得把递归逻辑全推翻了重写？

用迭代器模式改造

geng合理的Zuo法是把“怎么遍历树形菜单”这件事封装起来对外只暴露统一的遍历Neng力。咱们来手写一个 MenuCollection 类。

这里我们用栈来实现一个深度优先遍历，顺便处理一下隐藏项：

class MenuCollection {
  constructor {
    this.tree = tree;
  }
   {
    // 用栈模拟递归调用栈
    const stack = .reverse;
    return {
      next:  => {
        while  {
          const current = stack.pop;
          // Ru果有子节点，倒序压入栈中，保证遍历顺序和原始数据一致
          if  {
            stack.push);
          }
          // 遇到隐藏菜单跳过但继续遍历它的子节点
          if  {
            continue;
          }
          // 找到有效值，返回
          return { value: current, done: false };
        }
        // 栈空了遍历结束
        return { value: undefined, done: true };
      }
    };
  }
}

这样改造之后外部使用的人就不需要关心内部是递归还是用栈，也不需要管怎么过滤隐藏项。代码瞬间变得极其清爽：

const menus = new MenuCollection;
for  {
  renderMenu;
}

这就是迭代器模式Zui核心的价值：把“怎么遍历”封装起来让使用者只关心“我拿下一个元素就行了”。

进阶技巧：生成器的降维打击

hen多同学kan到这里通常还会碰到另一个概念：Generator。它和迭代器模式也有hen强的关系。

你想想，咱们刚才手写 next 方法，还得自己维护状态，是不是有点累？在 JavaScript 里我们Ke以用生成器geng省事地实现同样的效果。

生成器不是迭代器模式本身，但它经常是实现迭代器模式时一个特别顺手的工具。咱们把上面的 MenuCollection 改造一下：

class MenuCollection {
  constructor {
    this.tree = tree;
  }
  // 注意这个星号 *
  * {
    const stack = .reverse;
    while  {
      const current = stack.pop;
      if  {
        stack.push);
      }
      if  {
        continue;
      }
      // yield Ke以理解为“产出当前值，并暂停函数执行，等待下一次继续”
      yield current;
    }
  }
}

这里的生成器写法，本质上还是在实现迭代器，只不过语法geng简洁，kan起来也geng顺。当你执行 for...of 循环时JS引擎会自动帮你处理 next 的调用和状态的恢复。

策略调整：想换遍历方式？易如反掌

迭代器模式还有一个hen实用的地方，就是后续hen容易调整遍历策略。

比如现在我们实现的是深度优先遍历，Ru果后面产品经理突然发话，说“咱们要改成广度优先遍历”，那我们只需要改 MenuCollection 里的迭代逻辑，把栈换成队列，而不用去动外部使用代码。

外部代码依然是那个简单的 for...of 循环，完全感知不到底层的翻天覆地的变化。这对于大型项目的维护来说简直是福音。

你早就在用了

其实在 JavaScript 里迭代器模式你早就在用，只是hen多时候没专门意识到。

这些数据之所以douNeng被 for...of 遍历，本质上就是因为它们实现了迭代器相关协议。Ru果每一种数据结构，你dou自己写一套遍历逻辑，那业务代码hen快就会和数据结构细节绑死，Zui后变成谁dou不敢动的“屎山”。

所以两者的关系Ke以这样理解：

Iterator 是具体的执行者，负责一步步干活。

Iterable 是接口规范，承诺“我Ke以被遍历”。

Generator 是生成 Iterator 的快捷工具。

对于前端开发来说迭代器模式非常实用，像 for...ofMapSet树形菜单遍历、分页数据消费这些场景里douNengkan到它的影子。它本质上就是帮我们把“怎么遍历”从“怎么使用数据”里拆开，这样代码会geng清晰，后面改起来也geng从容。

下次当你再写下 for 的时候，不妨在心里默默点个赞，感谢这个设计模式让你少写了好多代码。

---