延迟执行通过按需拉取提升性能，体现为数据源仅遍历必要次数、内存占用近常量、结果反映数据源最新状态、底层含迭代器状态机或闭包结构。

识别迭代器的延迟执行对性能的提升，关键在于观察“计算是否真的发生”以及“何时发生”。它不靠直觉判断，而要从数据源访问行为、内存占用变化和执行时机三个维度验证。

看数据源是否被多次或提前遍历

延迟执行的核心是“按需拉取”，一次也不多读。如果一个查询链（如 Where → Select → First）最终只取第一个匹配项，那整个数据源应仅被遍历到找到该元素为止，而不是全量扫描。

• 用带日志的模拟数据源测试：在 GetEnumerator 或 MoveNext 中插入打印，确认只触发必要次数
• 对比立即执行版本（如先 .ToList() 再操作）：延迟版耗时更短、且日志输出条数明显更少
• 特别注意链式调用中终止操作符（First、Any、Take(1)）——它们能提前结束迭代，放大延迟优势

测内存占用是否随数据规模线性增长

延迟执行通常不缓存中间结果，因此处理百万级列表时，内存峰值应接近常量级，而非与集合长度成正比。

• 用 GC.GetTotalMemory 在查询定义前后、枚举前后分别采样，观察增量是否微小
• 若调用 .ToList() 后内存暴涨，而仅定义 var q = source.Where(...) 时几乎无变化，说明延迟生效
• 对流式场景（如文件逐行处理、网络响应流），延迟执行可避免一次性加载全部内容到内存

验结果是否反映数据源的最新状态

延迟执行意味着每次枚举都重新读取原始数据。修改数据源后再次遍历，结果应随之改变——这不是 bug，而是延迟执行的天然特征，也反向证明它没做预计算。

• 定义 var q = list.Where(x => x > 10)，再往 list 添加新元素，随后 foreach 枚举 q，新元素若被包含，说明执行发生在枚举时
• 若同一查询被枚举两次，且源数据在两次之间变更，两次结果不同，即为典型延迟行为
• 这种“数据敏感性”虽带来副作用风险，但也意味着没有冗余快照开销，适合实时性要求高的场景

查调用栈中是否出现 yield return 或迭代器状态机

底层实现上，C# 的 yield return 方法编译后会生成 IEnumerator 状态机类；Go-linq 中的 Iterate 函数返回闭包，内部含循环控制逻辑。这些结构本身即是延迟执行的信号。

• 反编译 LINQ 方法（如 WhereIterator 类）可看到私有字段保存 predicate 和 source，但无实际数据容器
• 调试时在枚举开始处设断点，进入的是迭代器的 MoveNext，而非原始集合的 foreach 循环体
• IDE 提示类型为 IEnumerable<t></t> 而非 List<t></t> 或 T[]，是延迟执行的静态标识