Reactor中Flux和Mono的泛型推导依赖编译期上下文（如字面量、lambda返回值），转换需显式cast/map/ofType等操作；泛型擦除导致运行时类型丢失，应使用ParameterizedTypeReference等规避。
Java中Reactor的Flux和Mono在泛型类型推导与转换时，核心在于编译期类型检查与运行时实际数据流结构的匹配。类型推导依赖于方法链式调用中的泛型参数传递，而转换则需显式声明或借助操作符完成，否则容易出现编译错误或运行时类型不匹配。
泛型类型如何被自动推导
Reactor利用Java 8+的类型推导机制，在链式调用中根据上游返回值、lambda参数、构造器入参等上下文自动确定泛型参数。例如：
-
Flux.just("a", "b")→ 编译器推导为Flux<String>，因为字面量是String -
Mono.fromSupplier(() -> 42)→ lambda返回int，自动装箱为Integer，推导为Mono<Integer> -
flux.map(s -> s.length())→ 若flux是Flux<String>，则map的lambda参数类型为String，返回int，推导出结果为Flux<Integer>
常见类型转换场景与写法
当自动推导失败或需要改变流的泛型类型时，必须显式干预。典型方式包括：
- 使用
cast()：强制转换元素类型（运行时检查，可能抛ClassCastException），如flux.cast(Number.class) - 使用
map()或flatMap()做有逻辑的类型映射，如mono.map(obj -> (String) obj)或flux.map(JsonNode::asText) - 用
ofType()过滤并转换类型：flux.ofType(String.class)只保留String实例，返回Flux<String> - 从
Mono<T>转Flux<T>用flux()，反之用next()或single()（注意空/多元素异常）
泛型擦除带来的限制与规避
Java泛型在运行时被擦除，导致Reactor无法在运行时感知具体类型（如Flux<List<String>>在运行时只是Flux<Object>）。这会影响：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 序列化/反序列化（需显式传
TypeReference或ParameterizedTypeReference） - 某些操作符行为（如
collectList()返回Mono<List<T>>，但T无法动态获取） - 调试时日志显示为
Flux<?>而非真实类型（IDE和Lombok等工具可辅助增强）
建议在关键转换点添加明确的泛型声明，例如：Mono.<User>empty() 或 Flux.<String>fromIterable(list)，避免依赖隐式推导。
嵌套泛型与高阶流的类型处理
面对Mono<Flux<T>>或Flux<Mono<U>>这类结构，类型更易混淆：
-
flatMapMany()用于展开Mono<Flux<T>>→ 得到Flux<T> -
flatMap()用于展开Flux<Mono<U>>→ 得到Flux<U> -
switchMap()语义类似flatMap()但会取消前序订阅，适用于切换场景 - 若需保留外层容器结构（如保持
Mono<Flux<T>>），避免使用扁平化操作符，改用map()配合函数式封装
此时推荐用ParameterizedTypeReference配合bodyToMono()等WebClient方法，确保HTTP响应解析类型准确。
