__iter__ 必须返回迭代器而非数据，因Python迭代机制只认迭代器协议（含__next__且耗尽时抛StopIteration）；直接返回列表等虽可迭代，但丧失控制权、无法干预next()行为、多次遍历状态共享。
为什么 __iter__ 必须返回迭代器，而不是直接返回数据？
因为 Python 的 for 循环、list()、next() 等机制只认「迭代器协议」：对象要有 __next__ 方法，且在耗尽时抛出 StopIteration。如果 __iter__ 直接返回列表或生成器表达式（比如 return self.data），而 self.data 是 list，那它确实可迭代——但这是靠 list 自己实现了迭代器协议；你的类只是“借壳”，没真正控制迭代逻辑。
正确做法是让 __iter__ 返回一个满足协议的对象：
- 返回一个自定义迭代器类的实例（推荐，逻辑清晰、可维护）
- 返回生成器函数（即含
yield的函数）的调用结果（简洁，但状态封装弱） - 避免返回
iter(self.data)除非你明确只需要代理行为且不扩展逻辑
示例中常见错误：def __iter__(self): return self.data —— 这会让多次遍历共享内部状态（比如 list 的索引不可控），也失去对 next() 行为的干预能力。
自定义迭代器类里，__next__ 怎么写才不出错？
核心就两点：有明确的终止条件 + 每次调用返回下一个值。最容易踩的坑是忘记维护游标、越界不抛异常、或在耗尽后继续返回值。
立即学习“Python免费学习笔记（深入）”；
典型结构：
class MyIterator:
def __init__(self, data):
self.data = data
self.index = 0
def __next__(self):
if self.index >= len(self.data):
raise StopIteration
value = self.data[self.index]
self.index += 1
return value
- 必须显式检查边界，不能依赖
try/except IndexError—— 迭代器协议要求抛StopIteration，不是IndexError - 不要在
__next__里重置self.index，否则会导致无限循环 - 如果数据支持动态修改（如边迭代边增删），需额外考虑一致性，通常建议迭代期间禁止修改
用生成器函数实现 __iter__ 时，哪些细节会影响行为？
写成 def __iter__(self): yield from self.data 或手动 yield 是合法且常见的，但要注意：
- 每次调用
__iter__都会创建新生成器，天然支持多次独立遍历（这点比返回同一迭代器实例更安全） - 生成器无法倒带或重复使用，符合迭代器语义，但没法像类迭代器那样暴露
.reset()或.peek()等方法 - 如果需要在迭代中访问外部状态（如计数、缓存、IO 控制），生成器函数的闭包变量不如类属性直观，容易引发意外共享
- 调试困难：生成器对象没有公开的当前状态字段，
print(gen)看不到游标位置
所以简单代理用生成器，复杂逻辑（如分页、过滤、懒加载）优先用独立迭代器类。
为什么 __len__ 和 __getitem__ 不能替代 __iter__？
有些同学以为只要实现了 __getitem__（支持下标访问）和 __len__，Python 就会自动提供迭代——这没错，但它是「后备机制」：当类没定义 __iter__ 时，解释器会尝试用 __getitem__ 从 0 开始调用，直到抛出 IndexError。
- 这种自动迭代无法中断或定制（比如跳过空项、提前退出）
- 如果
__getitem__不是 O(1)（比如要查数据库），性能灾难 - 一旦你加了
__iter__，后备机制就失效了，哪怕你写的是pass—— 所以别依赖它 -
__len__完全无关迭代协议，只是方便len()调用；很多可迭代对象根本没法高效算长度（如文件行、网络流）
真正可控、可预测、可扩展的迭代，必须显式实现 __iter__，而且它的返回值必须严格遵循迭代器协议——这个契约比看起来更硬，绕不开。
