现场是这样的。Dify 0.6.14 的迭代节点处理 150 条评论，跑到第 100 次就返回空数组，日志只有 iteration finished，没有任何报错；把输入截到 90 条就正常出结果，工作流里迭代节点后面直接接了汇总节点。
中间走过弯路，把「并行模式开了 10 路，节点超时提前结束」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。迭代节点默认上限 100 次，超出部分被静默丢弃；迭代次数取自数组长度，但变量引用的是分页后的子数组；输出变量只保留最后一次迭代的结果，前面的被覆盖。
第一件事是导出工作流 DSL 看迭代节点的上限配置
python -c "import yaml;w=yaml.safe_load(open('app.yml'));print([n for n in w['workflow']['graph']['nodes'] if n['data']['type']=='iteration'])"接着把输入按 80 条分批后再进迭代
python split.py --input comments.jsonl --size 80 --out parts/然后在 DSL 里提高 max_iterations 并重新导入
python -c "import yaml;w=yaml.safe_load(open('app.yml'));print(w['workflow']['graph']['nodes'][0]['data'].get('max_iterations'))"末了用 150 条全量数据复跑并核对条数
python check_counts.py --expect 150 --result out.jsonl恢复的判定其实很直接。150 条输入全部产生对应输出，汇总节点拿到的数组长度为 150，日志里迭代次数与实际条数一致。
这里还有个坑。迭代节点的上限是为了防止死循环，默认值很小；数据量超过 100 时要么分批，要么显式调大上限，不要指望它自动扩展。这类问题最好一次改到位，反复小改反而容易把原因搅混。