NoSuchElementException 总在调用 next() 时抛出，因迭代器或 Scanner 已到末尾却未校验 hasNext() 或 hasXXX() 就强行取值；常见于混用 nextXXX() 与 nextLine() 导致换行符残留、显式迭代漏判、或 Scanner 状态共享未重置。
为什么 NoSuchElementException 总在调用 next() 时炸？
因为迭代器或 Scanner 已走到末尾，你还硬要取下一个元素——它真没了，不是藏起来了。
这错误不怪代码写错逻辑，而是没做「存在性校验」就直接取值。Java 的设计很直白：不自动兜底，也不抛更友好的提示，就扔个 NoSuchElementException。
-
Iterator.next()必须搭配hasNext()用，缺一不可 -
Scanner.nextXXX()（如nextInt()、nextLine()）同理，得先确认有输入可读 - 特别注意
Scanner在控制台交互中，用户按 Ctrl+D（Linux/macOS）或 Ctrl+Z（Windows）才真正“结束输入”，光回车不算
Scanner 读完一行后接着读整数，为什么崩在 nextInt()？
这是经典换行符残留问题：用 nextLine() 后，缓冲区可能还剩一个未消费的 \n，下一次 nextInt() 会跳过空白但不跳过这个残留换行，结果立刻判定“没整数可读”，抛 NoSuchElementException。
- 别混用
nextXXX()和nextLine()——尤其避免nextInt()后紧跟nextLine() - 统一用
nextLine()读所有输入，再手动解析：Integer.parseInt(scanner.nextLine().trim()) - 如果非要用
nextInt()，之后加一句scanner.nextLine()清掉残留换行
遍历集合时用 for-each 却还是遇到 NoSuchElementException？
说明你没在用 for-each，而是在循环里偷偷调了 iterator.next() ——比如在 while (it.hasNext()) 里漏掉了 hasNext() 判断，或者多调了一次 next()。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
-
for-each是安全的，它底层自动包了hasNext()+next()，不会越界 - 一旦自己显式获取
Iterator，就必须严格配对：if (it.hasNext()) { it.next(); }，不能省略if - 注意并发修改：边遍历边用
list.remove()会触发ConcurrentModificationException，不是NoSuchElementException，别混淆
如何让错误现场更容易定位？
默认的 NoSuchElementException 没带任何上下文，堆栈只告诉你崩在第几行，但不知道是哪个 Scanner 或哪段迭代逻辑出的问题。
- 给自定义
Iterator实现时，在next()抛异常前加点线索：throw new NoSuchElementException("MyIterator exhausted at index " + currentIndex); - 对
Scanner，包装一层工具方法：safeNextInt(Scanner s, String prompt)，内部先hasNextInt()，失败时打印prompt再抛异常 - 单元测试里故意传空输入流（
new Scanner(new ByteArrayInputStream(new byte[0]))），验证是否真做了防护
最常被忽略的是：同一个 Scanner 对象在多个方法间传递时，没人记得它已经读到哪儿了。状态是共享的，不是每次调用都重置。
