Smallrye Mutiny 不支持直接封装返回 void 的受检异常方法，但可通过在 Unchecked.supplier() 的 lambda 中显式添加 return null 将其转为 Supplier，从而构建 Uni 并统一进行异常转换与异步处理。
smallrye mutiny 不支持直接封装返回 void 的受检异常方法，但可通过在 `unchecked.supplier()` 的 lambda 中显式添加 `return null` 将其转为 `supplier
在响应式编程中，Smallrye Mutiny 的 Uni 本质是“单值异步容器”，其泛型类型 T 必须可实例化——而 Java 的 void 不是类型，不能作为泛型参数；因此 Uni 实际表示“完成但不发射任何有效值”的信号（Void 是一个不可实例化的占位类，仅用于类型系统标记）。这正是处理无返回值操作（如 setBucketLifecycle()）的理想语义。
但直接写 Unchecked.supplier(() -> minioClient.setBucketLifecycle(...)) 会报错，原因有二：
- Lambda 表达式体为
void方法调用，编译器推断其返回类型为void，而Supplier要求返回T； -
Uni.createFrom().item(...)期望接收Supplier，无法接受void表达式。
✅ 正确解法是在 lambda 内显式执行 void 方法，并补上 return null;，使签名匹配 Supplier：
Uni<void> setLifecycleUni = Uni.createFrom().item(Unchecked.supplier(() -> {
minioClient.setBucketLifecycle(
SetBucketLifecycleArgs.builder()
.bucket(bucketName)
.config(lifecycleConfiguration)
.build()
);
return null; // ✅ 强制返回 Void（即 null），满足 Supplier<void>
}));
// 统一错误转换 + 阻塞等待（生产环境建议非阻塞链式处理）
CommonSystemErrorException error = setLifecycleUni
.onFailure().transform(e ->
new CommonSystemErrorException("Failed to set MinIO bucket life cycle configuration", e))
.await().indefinitely(); // 若需同步结果，否则应链入 .subscribe().with(...) 或组合进更大流</void></void>
⚠️ 注意事项：
-
不要滥用
await().indefinitely()：该调用会阻塞当前线程，违背响应式非阻塞原则。在 WebFlux/Quarkus 等环境中，应将Uni作为上游流的一部分，通过.onItem().transformToUni(...)或.andAwait()（配合Uni.combine()）参与编排，实现真正的异步协作。 -
Unchecked.supplier()的本质是包装try-catch：它将所有受检异常转为RuntimeException，由 Mutiny 的onFailure()统一捕获。这意味着原始异常的类型信息（如ErrorResponseException）会被抹除——若需保留分类处理，建议自定义Supplier或改用Uni.createFrom().failure(...)显式构造失败项。 -
资源与事务边界需额外保障：
setBucketLifecycle是外部服务调用，失败后无自动回滚。若该操作属于关键业务流程（如配置变更需幂等或补偿），应在onFailure()后衔接重试策略（.onFailure().retry().atMost(3)）或降级逻辑（.onFailure().recoverWithItem(...)），而非仅转换异常。
总结来说，return null 不是权宜之计，而是对 Void 类型语义的精准利用：它明确表达了“我只关心操作是否成功完成，不关心返回值”，这恰恰契合了命令式副作用操作在响应式流中的建模本质——Uni
