Python 3 的 map 和 filter 默认返回延迟计算的迭代器，仅在遍历时逐个执行，无需额外封装；误用 list() 等会立即触发全部计算，丧失延迟优势。
map 和 filter 在迭代器中默认就是延迟计算的
Python 的 map 和 filter 返回的是迭代器（Python 3），不是一次性生成全部结果的列表。这意味着调用它们时几乎不消耗内存和 CPU，只有在真正遍历（比如用 for、next() 或转成 list()）时才逐个计算。不需要额外封装或“开启”延迟特性——它本来就是。
常见误解是以为要手动写生成器函数才能延迟，其实直接用原生 map 和 filter 就已满足大多数延迟计算场景。
- 错误现象：
list(map(...))或[x for x in map(...)]立即触发全部计算，失去延迟优势 - 正确做法：保持返回值为
map/filter对象，只在需要时取部分元素 - 典型使用场景：处理大文件行、无限序列（如
itertools.count()）、IO 流式解析
filter 里传入 None 与传函数的行为差异
filter(None, iterable) 是快捷写法，等价于保留所有“truthy”值（非空字符串、非零数字、非空容器等），但要注意它不会跳过 False、0、"" 这类 falsy 值——这常被误认为“去空”，实际是“去假值”。而显式传函数（如 lambda x: x > 0）才能精确控制逻辑。
- 传
None：简洁，但语义模糊，容易在数据含0或False时出错 - 传函数：明确意图，支持任意条件，且可复用（如提前定义
is_positive = lambda x: x > 0） - 性能影响：无实质差异；但若函数有副作用（如打印、计数），延迟计算下副作用也延迟发生，需留意执行时机
嵌套 map/filter 时链式调用比中间转 list 更省内存
把多个转换/过滤串起来时，写成 map(f2, filter(f1, data)) 比 map(f2, list(filter(f1, data))) 更高效。后者会先构建完整中间列表，前者全程维持单个迭代器链，空间复杂度始终为 O(1)（忽略函数栈开销）。
示例：从一长串数字中只取偶数、再平方
data = range(10**6) # ✅ 延迟、低内存 result_iter = map(lambda x: x**2, filter(lambda x: x % 2 == 0, data)) <h1>❌ 生成百万级中间列表，浪费内存</h1><p>intermediate = list(filter(lambda x: x % 2 == 0, data)) result_list = list(map(lambda x: x**2, intermediate))
- 链式调用中任意环节都可随时中断（如只取前 5 个：
list(itertools.islice(result_iter, 5))） - 调试时可用
itertools.tee分叉迭代器，但注意分叉后原迭代器仍只能消费一次 - 不要对同一个迭代器对象重复遍历——它是一次性的，二次遍历为空
自定义迭代器助手需小心 __iter__ 和 __next__ 的实现边界
如果自己封装 MapIterator 或 FilterIterator 类，核心是确保 __iter__ 返回自身，__next__ 按需调用下游迭代器并应用函数。最容易踩的坑是：在 __init__ 中就预取了全部数据，或者在 __next__ 里没正确处理 StopIteration。
- 必须捕获下游
StopIteration并向上抛出，否则迭代永远不会结束 - 函数执行异常（如除零、键不存在）应在
__next__中原样抛出，便于定位问题位置 - 若需支持多次遍历，得在
__iter__中返回新实例，而非return self
延迟计算的优势全系于“按需触发”这一条铁律。一旦某处不经意 materialize 了整个序列（比如日志里写了 print(list(it))），前面所有优化就归零了。
