Quarkus Resteasy Reactive中Uni<List<T>>与Multi<T>有何差异？

两者的核心区别 #

• HTTP响应方式

  • Uni<List<T>>：会把整个List一次性序列化成完整的JSON数组，返回一个标准的HTTP响应。客户端必须等待所有数据准备完毕，才能接收完整内容。
  • Multi<T>：默认采用分块传输编码，逐个发送每个元素。客户端可以边接收边处理数据，不用等全量数据就绪，尤其适合大数据量场景。

• 元素处理的便捷性

  • 你提到的这点很准确：Multi<T>能直接通过onItem().transform(fruit -> ...)对单个元素做DTO转换、过滤，逻辑更细粒度，代码写起来更顺手。
  • Uni<List<T>>只能先拿到整个List，再通过遍历（比如stream流）处理每个元素，写法相对繁琐，比如得写成onItem().transform(list -> list.stream().map(fruit -> ...).collect(Collectors.toList()))。

• 底层数据加载逻辑

  • Uni<List<T>>对应一次性全量加载数据的操作（比如JPA的listAll()），所有数据会一次性加载到内存中。
  • Multi<T>适配流式数据获取（比如数据库流式查询、消息队列消费），数据分批加载，内存占用更低，处理大量数据时优势明显。

为什么Quarkus指南优先用Uni<List>？ #

• 新手友好，降低学习门槛
  对刚接触响应式的开发者来说，Uni<List<T>>的行为和传统同步REST端点很像——都是一次性返回全量数据，只是多了个响应式包装，更容易理解上手，不用额外啃分块传输、流式处理这些概念。

• 适配多数常规业务场景
  大部分业务接口返回的数据量都不大，一次性加载全量数据的性能开销可以忽略，而且Uni<List<T>>的实现更简单，不用考虑流式处理的额外配置（比如背压处理）。

• 兼容性更强
  有些客户端或API网关对分块传输的支持可能有问题，Uni<List<T>>返回的标准JSON数组兼容性更好，不会出现解析异常。另外，监控、日志工具对完整响应的处理也比分块响应更直观。

• 避免无意义的复杂度
  如果业务场景不需要流式处理的优势（比如数据量小、不需要实时推送），用Multi<T>反而会增加不必要的复杂度，比如要处理元素流的生命周期、背压等问题。

该怎么选？ #

• 要是你需要处理大数据量、实时流式数据，或者希望客户端能边接收边处理，优先用Multi<T>。
• 要是数据量不大，追求简单直观和兼容性，Uni<List<T>>更合适。

内容的提问来源于stack exchange，提问作者Olivier Boissé