举一个很简单但是一般业务场景不会使用的例子，比如你有一个任务负责从队列中获取最新的记录进行处理但是有一些通用的处理方法时就有用,假设你的消费端需要的是一个 pydantic 对象，可以用类型注释传进去序列化后再触发方法，如果消息不合规，则通过 MQ 路由或者其他方式去进行消费，甚至于你可以穿一个 match 的方法自己去实现一个路由

感觉迭代器主要用于声明一些接口的参数类型 例如，[any]( https://docs.python.org/3/library/functions.html#any) 的第一个参数，如果是 list 的话那必须全部展开，把每个值都算出来，但有时候不想算全部的值，或者出于性能考虑不想往后面算 所以像 any, all 这类函数，参数类型声明为 Iterable 表明其对参数的要求比 List 更弱，只需要一个可迭代对象即可，可以是 list 也可以是 set 更不必说内置函数的 map, filter, zip 等的参数类型都是 Iterable 还有内置的 itertools 包提供了很多强大功能，如 itertools.product 计算任意多序列的笛卡尔积

迭代器的使用实际上就是面向接口编程。作为库或者其他函数提供者，你不再需要了解传入的参数是不是一个列表。只要能用迭代器对应的方法即可。

或者我们可以让在一个具体的场景里面理解这个问题，举个例子，你需要从远程数据库中大量的数据。当然，你可以选择一次性把所有的数据都读取出来，另外一种做法是返回一个 cursor ，然后根据游标去 iter 这个表里的数据。iter 在这个时候的的好处是，你无需一次性的占用大量的内存和网络带宽/IO 用于传输存储数据，尤其是没有 patch 的同步环境下可能导致的长时间阻塞

延迟求值

如果我要实现类似 Makefile 的功能：一个文件的内容依赖于若干其他文件，当这些依赖的文件的任意一个的修改时间比目标文件新，就执行生成指令 假设 modify_time 函数可以获取文件的修改时间，使用如下 generator expression: ``` if any(modify_time(dep) > target_mtime for dep in deps): ``` 可以表达“只要有一个依赖文件比目标文件新”，后面的文件都可以不用打开（不调用 modify_time ）

作为一个已经工作了 8 年的程序员，看到大家的回答，虽然心里......but "love and peace,谢谢大家"。我们限定一下问题————“大家在实际工作中自己实现过的迭代器是怎么样的？”

不知道为什么，楼主的语气给我一种故作谦虚但内心高傲的感觉……

自定义迭代器主要有几个场景，一是修改可迭代数据的行为，例如将有序列表对象以乱序读取，例如给一个 gif 抽帧；二是给不可迭代数据添加一个迭代行为，例如可以把一棵树以某种策略输出为扁平化列表；三是迭代行为与其他逻辑紧密相连，例如读取文件信息、写入数据、关闭资源，下一个文件的选择、处理方式与上一个有关，这么一坨东西可以放迭代器里。 对外部模块来说，这一部分复杂度就转移进迭代器里了，它不用关心多余逻辑，只管 for 就行了，本质上是抽象与组织代码的权衡。 相比生成器，迭代器的优势场景在于： 1. 维护复杂的内部状态管理，简单依靠恢复/暂停不好实现，例如要维护一个状态机。 2. 要公开某些状态给外部，例如公开进度条、统计信息。 3. 行为逻辑更加 OOP ，如果你的 Python 代码充满了 OOP 的味道会更合适。 其余情况还是用生成器更好。 当然，并非一定要用迭代器/生成器实现，完全不使用也照样能做，取决于个人习惯。你说实际应用中没看过自定义的迭代器，非常正常，因为该程序员不希望把逻辑放进迭代器的内部，这本质上是垃圾放一楼还是二楼的问题，其实没有区别。编写代码有 114514 种抽象方法，你不用 xxx 代码照写世界照常运转并没什么影响，唯一影响是你没尝试过不能切身判断它到底好不好，适不适合你或者你的代码。

@codists 其实我认为工作中用不到，很大一部分原因是可读性、维护性的原因，如果团队中的成员水平参差不齐，过分的追求语法糖只会增加自己的工作量