Spring Reactive WebClient使用any()短路后偶发连接提前关闭问题咨询

看起来你遇到了一个挺闹心的偶发问题——升级Spring全家桶版本后，原本稳跑一年的测试偶尔会挂掉，抛出reactor.netty.http.client.PrematureCloseException: Connection prematurely closed BEFORE response，换了统计方式就好了对吧？咱们来拆解下这个问题到底是怎么回事，以及它到底是bug还是版本升级后的预期行为。

先理清楚问题的核心逻辑 #

你原来的代码逻辑是：发起5个请求，用Flux.merge(responses).any(...)短路查找是否存在4xx响应——只要找到第一个符合条件的响应，就会立即取消剩下还在执行的请求订阅。升级前的版本里，这种短路操作后的连接管理比较宽松，但升级后，这个取消信号的处理变得更严格了。

为什么升级后会出问题？ #

这里的关键变化可能来自两个层面：

1. Reactor Core 3.7.x的操作符行为调整
   升级到Reactor Core 3.7.x后，any()这类短路操作符的取消信号传播更及时、彻底了。原来3.6.x版本里，即使any()找到了第一个4xx并取消其他流，Reactor Netty可能还会把对应的连接保留在连接池里，或者优雅地完成连接的收尾；但3.7.x里，取消信号会直接触发连接的提前关闭，这个连接会被标记为无效。

2. Reactor Netty/Webflux的连接池管理更严格
   搭配Spring Webflux 6.2.x的Reactor Netty版本应该也做了升级（比如从1.1.x到1.2.x），新版本对连接的生命周期管理更严谨：当请求被主动取消时，会立即关闭对应的连接，而不是放回连接池复用。如果后续的WebClient请求刚好复用了这个被提前关闭的连接，就会抛出PrematureCloseException。

而问题“偶发”的原因也很明确：只有当any()确实触发了短路（也就是存在4xx响应）时，才会产生无效连接；如果所有请求都没有4xx，any()会等待所有请求完成，连接会被正常回收，后续请求就不会出问题。

这是bug还是预期行为？ #

更准确地说，这属于版本升级后的行为变化，而非bug。Spring/Reactor团队在新版本里优化了资源的生命周期管理，让取消信号的传播更及时，避免资源泄漏，但这也导致依赖旧版宽松行为的代码出现了兼容性问题。

关于你的修复方案 #

你换成count()的思路非常正确：count()会等待所有请求的响应都处理完成，不会提前取消任何流，所有连接都会被正常地完成并放回连接池，后续请求自然不会拿到无效连接。如果你的业务逻辑允许等待所有请求完成，这个方案是最稳妥的。

如果后续你需要保留短路逻辑（不想等待所有请求），可以试试这两个方向：

• 配置WebClient的连接池参数，比如调整连接的空闲超时时间，让无效连接更快被清理；或者增加连接池大小，降低后续请求复用无效连接的概率。
• 在短路操作后，给连接池一点时间完成清理，比如加个短暂的Mono.delay()再执行后续请求（不过这个方案不够优雅，不推荐作为长期解决方案）。

内容来源于stack exchange