为何Flux.zip搭配重复空Mono会生成无限Flux而非空Flux？

要搞懂这个差异，得拆解两个关键点：repeat()操作符对空/非空Mono的影响，以及Flux.zip的终止逻辑细节。

1. Mono.empty().repeat()的实际行为 #

Mono.empty()是一个直接发送onComplete信号、没有任何onNext发射的流。当调用.repeat()时，它的逻辑是：一旦源Mono完成，就重新订阅它。

所以Mono.empty().repeat()最终生成的是一个**无限循环发送onComplete信号、但始终没有onNext**的Flux。它永远不会真正终止，而是不断重复“订阅空Mono→立即完成→再订阅”的循环。

2. Flux.zip的核心规则 #

根据官方文档描述：

Zip two sources together, that is to say wait for all the sources to emit one element and combine these elements once into a Tuple2. The operator will continue doing so until any of the sources completes.

这里容易被忽略的细节是：终止的前提是某个源完成，且所有源都没有待配对的剩余onNext信号。如果有一个源还在重复订阅（即使不产生元素），Zip不会触发终止。

3. 两个案例的对比分析 #

案例1：非空Mono.repeat()（正常终止） #

Mono.just(1).repeat()生成的是一个**无限发射onNext(1)**的Flux：每次Mono发射1后完成，repeat重新订阅，继续发射1。

此时Flux.just("A","B","C","D","E")会发射5个元素后完成。Zip操作会：

• 每次等待字母流和数字流各出一个元素，配对输出5次
• 当字母流完成后，它已经没有更多待配对的元素，即使数字流还能继续发射，Zip也会终止（因为其中一个源已经完成且无剩余元素）

这就是为什么这个案例会正常结束，输出5组配对结果。

案例2：空Mono.repeat()（无限运行） #

Mono.empty().repeat()没有任何onNext，只有不断的onComplete和重新订阅。此时：

• 字母流的5个onNext已经全部发出，但Zip一直在等待数字流的onNext来完成配对，却永远等不到
• 数字流不断重复“完成→重新订阅→再完成”的循环，永远不会真正终止，也不会产生任何onNext
• Zip既无法完成配对输出，也无法触发终止条件（因为数字流没有真正终止，只是不断重复完成），最终导致整个流无限运行

4. 替换代码生效的原因 #

把Mono.empty().repeat()换成.flatMapMany(value -> Mono.just(value).repeat())后：

• Mono.empty()没有onNext信号，所以flatMapMany的lambda逻辑根本不会执行
• 最终生成的是一个**直接发送onComplete、无任何onNext**的空Flux
• 此时Zip遇到一个已经完成且无元素的源，会立即终止，输出空Flux，符合预期

内容的提问来源于stack exchange，提问作者Ogod