StopIteration异常被for循环等内置结构主动捕获并静默终止迭代，而非未处理导致崩溃；Python 3.5+起生成器内显式raise StopIteration会转为RuntimeError；DataLoader中抛出该异常通常因Dataset的__len__与实际数据长度不一致。
StopIteration异常本身不会“自动终止”程序，而是被for循环、list()、tuple()等消费迭代器的内置结构**主动捕获并静默处理**——这是Python迭代协议的设计约定，不是异常未被处理导致的崩溃。
for循环内部如何处理StopIteration
每次for x in iterable:执行时，解释器实际在底层调用next()获取下一个值；一旦next()抛出StopIteration，for立即退出循环体，不报错、不传播、不继续迭代。这个捕获是硬编码在CPython解释器中的，用户无法绕过或禁用。
- 你写
for i in []: print(i)不报错，是因为iter([]).__next__()第一次就抛StopIteration，for直接结束 - 手动调用
next(iter([]))则会立刻触发该异常——因为没人在外层捕获它 -
list(iterable)同理：它持续next()直到捕获StopIteration，然后返回已收集的列表
为什么不能在生成器里raise StopIteration
Python 3.5+ 强制执行PEP 479：任何在def ...: yield函数体内显式raise StopIteration，都会被解释器拦截并转为RuntimeError。这不是bug，是防止StopIteration意外逃逸出生成器边界，干扰上层for或yield from的控制流。
- 错误写法：
def g(): yield 1; raise StopIteration→ 实际抛RuntimeError: generator raised StopIteration - 正确写法：
def g(): yield 1; return "done"→ 迭代耗尽时触发StopIteration，且.value == "done" - 嵌套场景下，
yield from subgen也依赖这一机制：子生成器return的值会成为StopIteration.value，供父生成器接收
DataLoader报StopIteration通常意味着数据集不一致
PyTorch的DataLoader不期望从Dataset.__getitem__中收到StopIteration。它只接受IndexError（索引越界）或正常返回样本。如果__len__声明了100条数据，但__getitem__(99)内部因列表实际只有95个元素而raise StopIteration，就会中断worker线程并抛出该异常。
- 根本原因：自定义
Dataset中__len__和self.data长度不一致 - 典型误操作：在
__init__里先设self.data = raw_list，再过滤掉部分样本，却没更新__len__返回值 - 绝对不要在
__getitem__里写if idx >= len(self.data): raise StopIteration——改用return self.data[idx]让列表自己抛IndexError
真正容易被忽略的是：StopIteration的“静默终止”只发生在明确的迭代消费场景（for、list()、sum()等），一旦你手动调用next()或在生成器内部干预，它的行为就完全取决于你是否做了对应捕获——而PEP 479之后，连生成器内部的raise都不可信了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
