怎么在流式清洗拓扑中利用循环控制逻辑实现百万级对象的结构拉平

先一句话说清楚核心逻辑：在流式清洗场景下做结构拉平，关键不在于循环语句本身有多强，而是要用循环控制逻辑去驱动一种“按需展开、逐层解构、引用即用”的轻量执行模型。百万级对象如果还用传统嵌套循环去全量展开，内存溢出几乎是板上钉钉的事，GC压力也会飙升。真正有效的做法，是把“循环”从单纯的数据遍历工具，转变成拓扑调度的指令——它不负责承载数据，只定义展开的时机和边界。

用可中断的生成器循环替代全量嵌套

结构拉平——比如把 JSON 数组字段展开，或者把嵌套的 Map / List 展开成宽表——本质上就是“一对多”的映射。如果直接用 foreach 加 AddRange，一次性生成所有子项再暂存，那就又回到老路上了。正确的做法，是用 yield return 驱动的生成器循环，让每一轮只产出一个扁平化记录。

具体来说：对每个输入对象，先解析它的嵌套结构（比如 "items": [{"id":1},{"id":2}]），然后用 foreach (var item in obj.Items) 循环。但关键在于，每次循环只做一次 yield return new FlatRecord { ParentId = obj.Id, ItemId = item.Id }。消费端——比如下游的 filter 或 sink——按需取值，不会把整批结果都缓存下来。内存里始终只驻留当前正在处理的 1–2 个嵌套层级对象，而不是整个原始对象加上全部子项。

基于引用深度分层展开，避免长链强引用

拉平过程中，最容易被忽略的坑是中间结构持有父对象引用，导致 GC 无法回收。借鉴可达性分析的思想，可以分层处理：

• Layer-0（根层）：清洗任务上下文（比如 FlatContext），包含 schema、路径表达式（如 $.orders[*].items[*]）、输出字段映射。
• Layer-1（主对象层）：当前主对象解析的结果（比如 Order 实例）。推荐用 ReadOnlySpan 或不可变 JsonElement 表示，不要深拷贝。
• Layer-2（扁平记录层）：展开时动态构造的 FlatRecord。字段值优先复用父对象的 Utf8JsonReader.TokenStartIndex 这类偏移信息，避免字符串分配。

展开循环中，有一条硬性规则：不要将 Order 实例赋给 FlatRecord.OrderRef 这样的强引用字段。改用 WeakReference，或者只存一个 OrderId 字段。这样，一旦主对象被上游释放，它的子结构就自动变得不可达，JVM 或 .NET 的 GC 可以立即回收。

用惰性表达式树替代硬编码循环

像 Polars 这类引擎的拉平逻辑（比如 .unnest("items")），其实不写 for 循环，而是注册表达式节点。例如，UnnestExpr(path: "items", keepName: true) 被加入逻辑计划树。执行时，物理引擎按块（chunk）扫描，对每块调用 UnnestKernel——内部仍然有循环，但这个循环是无状态的，不累积中间 List，使用预分配的 ArrayPool 复用缓冲区，还支持 chunk 级别的并行展开（不是 record 级别）。

如果输入是 LazyFrame，.unnest() 不会触发计算，直到 .collect(streaming=true) 才启动流式展开。这种设计下，“循环”被封装在底层的向量化内核里，上层的清洗拓扑看到的只是声明式操作。

规避几个常见的陷阱

嵌套过深、重复展开、空数组膨胀——这几个问题看着简单，但实际踩坑的人不少。

• 对 $.a.b.c.d.e 这种超深路径，提前做 schema 探测，跳过不存在的层级，避免空循环。
• 同一字段多次 .unnest()（比如先 unnest items，再 unnest items.tags），要确保第二层是基于第一层输出的列名，而不是原始的嵌套对象。
• 空数组 [] 展开后默认产出 0 行。如果业务要求保留父记录，需要显式用 .with_columns(pl.col("items").list.len().alias("items_len")) 做兜底判断。

这几个细节不复杂，但容易忽略。