迭代、惰性与数据流

迭代、惰性与数据流

JS/TS 的 map/filter 会快速生成中间数组；Python 生成器可以延迟产生数据；C++ 迭代器和 ranges 让算法组合更接近数据流。选择时要看内存、消费速度和错误的传播方式。处理十条配置记录时，数组链的可读性通常比节省一次分配重要；处理一百万条日志、图片索引或传感器帧时，惰性管线可以把峰值内存从“所有中间结果”降到“当前窗口”。

惰性也改变了执行时机：创建生成器并不等于读取文件，真正迭代时才会发生 IO 和异常。JS 的异步迭代器、Python 的 yield、C++ 的 input range 都要求消费者明确何时结束。AI 数据清洗要考虑批大小和背压，机器人流要考虑丢帧策略，不能只看一段链式表达式是否漂亮。

学习目标

• 能区分 eager 集合变换与按需产生数据的惰性迭代。
• 能按峰值内存、提前终止、错误传播和消费者速度选择数据流模型。
• 能通过计数器确认实际消费数量，而不是因为创建了 iterator 就假定工作已经完成。

数组链在大数据上可能不是最好的模型

下面这段代码只保留同一个意图，重点观察输入边界、数据流和失败语义，而不是逐字符翻译。

const scores = events
.filter(event => event.valid)
.map(event => score(event));

# Python
scores = (score(event) for event in events if event.valid)

// C++
auto scores = events | std::views::filter(valid)
                       | std::views::transform(score);

何时物化，何时惰性

惰性管线适合一次消费、顺序读取和可控的生产速度；需要多次遍历、排序、随机访问或跨线程传递时，物化容器更直接。不要把“零中间数组”当成绝对目标：排序本来就需要看到完整输入，调试也可能需要保存样本。先用输入规模和消费者速度估算，再用内存/吞吐测量验证。

def valid_scores(lines):
    for line in lines:
        event = parse(line)
        if event.valid:
            yield score(event)

for value in valid_scores(open("events.jsonl", encoding="utf-8")):
    write_feature(value)

错误、终点与背压

生成器中的解析错误会在消费点抛出，调用方要决定跳过一行、记录错误还是停止整批。异步流还要定义关闭动作，C++ range 需要确保迭代器不引用已销毁的容器。若生产者快于消费者，应设置有界队列或批处理窗口；否则惰性语法仍可能让未消费的数据在上游缓存中无限积累。

常见错误与排错思路

最容易踩的是重复遍历一次性迭代器，第二次得到空结果；另一个是把生成器传给需要长度或索引的函数。排错时先打印“创建”和“首次消费”的位置，检查是否提前打开/关闭文件，再用小输入逐项比对 eager 与 lazy 版本。若内存仍持续增长，观察队列长度和缓存，而不是只盯着生成器代码。

把多步数组处理改为惰性管线

在小数据上，先创建完整数组往往更清楚；输入变大时，可以让每条记录经过同一条管线，只在需要时产生结果。生成器在“被消费”前不会执行主体，因此调试时必须同时检查创建与遍历两个时点。

function* validScores(rows) {
  for (const row of rows) {
    if (Number.isFinite(row.score) && row.score >= 0.8) yield row.id;
  }
}
const ids = [...validScores([{ id: "a", score: 0.9 }, { id: "b", score: 0.4 }])];
console.log(ids); // ["a"]

上面的展开运算最终仍会物化全部结果；若结果规模很大，应逐项写出、聚合或在找到足够结果后停止。Python 生成器和 C++ ranges 也有相同的惰性陷阱：迭代器若从未被消费，处理逻辑就不会发生。

验证消费量与背压

分别用 10 条和 100 万条记录比较峰值内存、处理时间与输出数量。为管线增加已读条数、已产出条数和丢弃条数；当生产者快于消费者时，设置有界队列或暂停上游读取，而不是无限缓存。加入一条非法记录，确认错误是停止整条流、跳过并计数，还是转入隔离队列。

若输出为空，先确认迭代器是否被消费、过滤条件是否正确；若内存持续增长，检查是否把惰性结果再次展开为数组，或把每个中间结果留在日志/缓存中。

迁移练习

请完成：把处理一百万条事件的数组链改造成不会一次性保存全部中间结果的管线，并指定解析失败时跳过还是终止、消费者变慢时如何限制缓存。

Python 用 yield 逐条解析并在消费点写出；C++ 用 ranges view 过滤和转换，最终消费到文件或有界队列。解析错误记录行号后跳过，队列达到上限时阻塞生产者或按业务规则丢弃旧帧。

小结

惰性处理减少中间集合，但会把执行时机、错误传播和背压责任推迟到消费端。对小数据优先可读性，对大数据先测峰值内存和吞吐，再决定是否需要流式管线。