本文介绍在 Spring WebFlux 中处理 FilePart 时，如何在完成数据流处理后一次性、安全地删除本地临时文件，同时不中断或丢失原始 Flux 的数据流。核心在于利用 doOnComplete 延迟执行清理逻辑，避免竞态与资源提前释放问题。
本文介绍在 spring webflux 中处理 `filepart` 时，如何在完成数据流处理后**一次性、安全地删除本地临时文件**，同时不中断或丢失原始 `flux` 的数据流。核心在于利用 `dooncomplete` 延迟执行清理逻辑，避免竞态与资源提前释放问题。
在基于 Project Reactor 的 WebFlux 应用中，处理上传文件（FilePart）常需将内容暂存为本地文件以支持流式解析（如 CSV/JSON 行解析），但必须确保该临时文件仅在所有数据项处理完毕后被可靠删除。直接在 flatMap 或 then 中触发删除会导致：
- 文件可能被过早删除（流尚未开始消费，
Flux还未订阅）； - 多次调用
deleteFile（因Flux内部操作可能多次触发flatMap分支）； - 主流
Flux被中断或丢弃（如误用then()替代doOnComplete）。
✅ 正确做法是：将删除逻辑绑定到 Flux 生命周期的 doOnComplete 钩子，确保它仅在所有元素发射完毕、流正常终止时执行一次，且不干扰上游数据流。
以下是优化后的实现：
Flux<classb> functionA(Mono<filepart> filePartMono) {
return filePartMono
.flatMapMany(filePart ->
fileHandlerService.saveFile(Mono.just(filePart)) // 注意：此处传入已解包的 filePart，避免重复 flatMap
.then(Mono.just(filePart))
.flatMapMany(this::getItems)
.doOnComplete(() ->
fileHandlerService.deleteFile(filePart)
.subscribeOn(Schedulers.boundedElastic())
.subscribe(
null,
error -> log.error("Failed to delete temp file: {}", filePart.filename(), error)
)
)
);
}</filepart></classb>
⚠️ 关键改进说明：
-
避免嵌套
Mono操作：原代码中filePartMono.flatMap(...)在flatMapMany内重复展开，易引发FilePart读取异常（FilePart不可重复订阅）。应先解包filePartMono，再复用filePart实例。 -
doOnComplete是声明式钩子：它不改变Flux数据流，仅在 onComplete 信号发出时触发副作用（如清理），完美契合“处理完再删”的语义。 -
显式错误处理：
.subscribe(...)中捕获删除失败日志，防止静默失败影响可观测性。 -
线程调度明确：
subscribeOn(Schedulers.boundedElastic())确保文件 I/O 在弹性线程池执行，避免阻塞事件循环线程。
? 补充建议：
- 若需更高可靠性，可结合
try-finally思路使用doFinally( signal -> { ... } )，覆盖onError和onComplete场景（但注意：onError时文件可能尚未完全写入，需按业务判断是否强制清理）。 - 生产环境推荐使用
java.nio.file.Files.createTempFile生成唯一临时路径，并在saveFile中记录路径，避免filePart.filename()被恶意构造导致路径遍历风险。 - 更优方案是绕过本地文件——直接用
filePart.content()返回的Flux解析流，彻底消除磁盘 I/O 开销与清理负担（适用于格式支持流式解析的场景）。
综上，doOnComplete 是 WebFlux 中实现“流结束后单次清理”的标准、简洁且响应式友好的方式。
