Reactor中doOnNext的副作用是否会被跳过？能否确保map已填充？

你完全可以确定，在fooToBar()方法执行时，当前处理的foo元素已经被放入了ConcurrentHashMap中。理由如下：

1. doOnNext的同步执行特性 #

Reactor中的doOnNext是同步、顺序执行的副作用操作符：

• 对于流中的每个元素，会先完整执行doOnNext内的lambda逻辑（也就是idToFoo.put(foo.getId(), foo)），只有当这个操作完成后，才会将元素传递给下游的flatMap操作符。
• 你的示例中没有指定任何自定义Scheduler，因此doOnNext和后续的flatMap会在同一个线程中处理当前元素，不存在异步执行导致的顺序问题。

2. 关于"fire and forget"的误解 #

资深开发者提到的"fire and forget"指的是异步执行的副作用——即触发操作后不等待其完成就继续下游逻辑。但doOnNext默认是同步执行的，它不属于这种场景：

• 只有当你为doOnNext指定了异步Scheduler（比如doOnNext(..., Schedulers.boundedElastic())），才会出现"fire and forget"的风险，此时put操作可能还没完成，下游就开始执行fooToBar。
• 你的代码中没有异步调度，所以完全不必担心这个问题。

额外注意事项 #

虽然当前元素的put操作能保证在fooToBar前完成，但要注意flatMap默认的并行度是2：

• 这意味着多个元素的处理可能并行进行，fooToBar中看到的idToFoo可能包含其他正在并行处理的元素，但当前处理的foo一定已经在map中。
• 如果需要保证所有上游元素都被放入map后再处理下游，可以考虑将flatMap的并行度设为1（flatMap(..., 1)），或者使用concatMap替代flatMap（串行处理）。

可选的更严谨写法 #

如果你想让代码的副作用逻辑更明确，也可以用map操作符替代doOnNext，效果完全一致，但语义上更强调"元素转换+副作用"：

public Flux<Bar> methodOne(final Flux<Foo> foos) {
    Map<UUID, Foo> idToFoo = new ConcurrentHashMap<>();
    return foos.map(foo -> {
            idToFoo.put(foo.getId(), foo);
            return foo;
        })
        .flatMap(foo -> fooToBar(foo, idToFoo));
}

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