延迟执行通过按需拉取提升性能，体现为数据源仅遍历必要次数、内存占用近常量、结果反映数据源最新状态、底层含迭代器状态机或闭包结构。
识别迭代器的延迟执行对性能的提升，关键在于观察“计算是否真的发生”以及“何时发生”。它不靠直觉判断，而要从数据源访问行为、内存占用变化和执行时机三个维度验证。
看数据源是否被多次或提前遍历
延迟执行的核心是“按需拉取”，一次也不多读。如果一个查询链（如 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>而非List<T>或T[]，是延迟执行的静态标识
