quarkus mutiny 不提供原生响应式 xml 解析器，需用 stax（xmlstreamreader）配合 multi.createfrom().emitter() 实现流式解析，避免阻塞和内存溢出，并正确处理异常与资源释放。
Quarkus Mutiny 中没有原生 XML 响应式解析器
Quarkus Mutiny 本身不提供类似 XmlParser 或 XmlSubscriber 的响应式 XML 工具类。Mutiny 的核心是围绕 Uni 和 Multi 构建异步数据流，但对 XML 这种结构化、需状态维护的文本格式，它不封装解析逻辑——你得自己桥接标准 XML 解析器与 Mutiny 流。
用 StAX + Multi 实现流式 XML 处理
最实用的方式是结合 Java 标准的 XMLStreamReader（StAX）和 Multi.createFrom().items() 手动驱动事件流。关键点在于：不能把整个 XML 加载进内存，而是边读边发事件；每个 START_ELEMENT 或 END_ELEMENT 对应一个 Multi 项。
常见错误是直接在 Multi.createFrom().items(() -> { ... }) 里阻塞读取，导致线程卡死。正确做法是用 Multi.createFrom().emitter() 异步推送，并确保在 IO 线程（如 executorIO）中运行解析逻辑。
- 使用
io.smallrye.mutiny.Uni.createFrom().item(() -> Files.newInputStream(...))获取输入流 - 通过
Multi.createFrom().emitter(emitter -> { ... })启动解析循环 - 每次调用
reader.next()后，用emitter.emit(event)推送封装好的事件对象（如XmlEvent.START("user")） - 务必在
emitter.fail()中处理XMLStreamException，否则错误会被静默吞掉 - 解析完成后调用
emitter.complete()，否则Multi永远不会终止
避免 JAXB + Uni 的陷阱
有人试图用 Uni.createFrom().item(() -> JAXBContext.newInstance(User.class).createUnmarshaller().unmarshal(input))，这看似简洁，但本质是同步阻塞反模式：
- JAXB
unmarshal()必须读完全部输入才能返回对象，完全失去“响应式”意义 - 大文件会 OOM，且无法背压控制
- Quarkus 的
@Blocking注解只能挪到线程池，不能改变其同步本质 - 如果输入源是 HTTP body（如
RestEasy Reactive的InputStream），JAXB 还可能因流已被消费而抛IllegalStateException
真正需要反序列化为对象时，应先用 StAX 流提取关键字段（如 ID、timestamp），再用 Multi.transform().byFilteringItemsWith() 聚合成完整对象，或交给下游服务异步处理。
实际可跑的 Minimal 示例（SAX 风格事件流）
以下代码片段在 Quarkus 3.x + Mutiny 2.x 下验证通过，用于从 classpath 读取 data.xml 并逐个发射 START_ELEMENT 名称：
Multi<String> xmlElementNames = Multi.createFrom().emitter(emitter -> {
try (InputStream is = Thread.currentThread().getContextClassLoader()
.getResourceAsStream("data.xml");
XMLStreamReader reader = XMLInputFactory.newInstance()
.createXMLStreamReader(is)) {
while (reader.hasNext()) {
int event = reader.next();
if (event == XMLStreamConstants.START_ELEMENT) {
emitter.emit(reader.getLocalName());
}
}
emitter.complete();
} catch (XMLStreamException | IOException e) {
emitter.fail(e);
}
});
注意：XMLInputFactory 默认不支持 namespace，若 XML 含 xmlns，需显式设 factory.setProperty(XMLInputFactory.IS_NAMESPACE_AWARE, true)；否则 getLocalName() 可能返回空。
XML 的响应式处理难点不在 Mutiny，而在如何把有状态的解析过程安全地映射成无状态的数据流。最容易被忽略的是异常传播和资源释放时机——emitter.fail() 必须覆盖所有 XMLStreamException 分支，且 InputStream 和 XMLStreamReader 必须在 try-with-resources 中关闭，否则连接或文件句柄泄漏会随请求量上升而暴露。
