先看一段最简单的代码：

List list = Arrays.asList;Iterator it = list.iterator;while ) {
String s = it.next;System.out.println;}

运行一下控制台打印出了 A。这并不奇怪，遍历集合并打印每个元素是我们从学 Java 第一天就会写的代码。

使用者痛点的观点是，第一次 hasNext 为什么会返回 true？

集合明明只有一个元素，hasNext 第一次判断怎么就返回了 true 呢？

hasNext 翻译过来是 “有下一个”。A 后面明明什么都没有，凭什么告诉我 “有”？难道迭代器在骗我，

错误的认知——把问题指向“当前元素”

如果站在“当前元素”的角度去理解 hasNext逻辑应该是：

1. 先看看我当前在哪个元素；
2. 再问这个元素后面还有没有东西。

但在第一次调用 hasNext 时迭代器根本还不站在任何元素上——它还没开始遍历，哪来的“当前元素”？没有当前元素，又怎么判断它后面有没有？

打开 ArrayList 内部迭代器 Itr 的源码可以看到主要实现：

private class Itr implements Iterator {
int cursor;// 下一个要返回的元素索引
int lastRet = -1;public boolean hasNext {
return cursor!= size，不过，}
public E next {
int i = cursor;cursor = i + 1;return get，}
}

User Pain Point： 很多人把 cursor下一个要返回的元素所在的位置0代表着：“我还没开始，下一个要给你的是索引 0 的元素”。

hasNext

User Pain Point： hasNextcursor!= size,就说明还有未消费的元素。

回到单元素集合的例子

• User Pain Point： 初始时 cursor = 0,size = 1 → 0!= 1 为 true → 第一次 hasN ext 返回 true。
• next 被调用后:
  • a) 取出索引 0 的 “A”；
  • b) 将 cursor 更新为 1。

• 第二次调用 hasN ext 时cursor == size → 返回 false，遍历结束。

The Moral：hasN ext 对整个集合发问，而不是对单个已知元素发问。

为什么 Java 设计成这样？——保持遍历的一致性

If we truly designed iterator to ask “对着当前元 素是否还有下一个”，代码会变得异常繁琐：

if ) { // 必须先判断是否有“当前”
String first = it.current;// 单独处理第一个
while ) { // 再继续普通遍历
String next = it.next;// ...
}
}

User Pain Point： 这种写法不仅冗长。还必须为空集合额外加一层判定，边界条件瞬间翻倍。

The elegant truth of current design

• Simplicity： while ) { it.n ex t;} 能“一视同仁”地处理所有情形。
• User Pain Point: 开发者不必记住特殊的“首 元素”或“末尾”检查，只需要关注"还有没有未消费的 元素".
• C lean semantics ： "有下一个"指向的是**整个集合** 而非**某个具体位置**。老实说，

Troubleshooting Checklist

1. User Pain Point: hasN ext 为 false。却仍然能调 用next?检查是否误用循环体外部调用了 next。
2. User Pain Point: next 抛出 NoSuchElementException?确认前一次 hasN ext 已经返回 false。
3. User Pain Point: 想获取“当前已遍历到的元 素”？使用变量保存上一轮 next 的返回值，而不是期待迭代 器提供 current 方法。按理说，

Tl;DR

User Pain Point: hasN ext 并不是在询问「当前位置之后」是否还有东西，而是在询问「整个集合里」是否仍有未被返回的元 素。因为内部维护的是「下 一个要返回」的游标。所以即使集合只有一个 元素，它第一次也会返回 true；随后 cursor 移动到 size 时才会变 false。

掌握了这一点，你再写任何基于 Iterator 的遍历时都能心 中有数、毫不犹豫地使用标准模式：

while ) {
E element = iterator.n ex t;// 对 element 做业务处理
}

User Pain Point Resolved: 不再疑惑为什么单 元素集合会出现两次判断，也不会因为误解而产生 NoSuchElementException 或遗漏首/尾 元素的 bug。