RxJava中flatMap多API调用合并结果用法是否正确？如何替代全局变量？

解答 #

你的实现虽然能正常运行，但确实不是最优解——嵌套的flatMap把代码搞成了“回调地狱”，可读性和维护性极差，而且依赖全局的resultsList还可能引发线程安全或者数据混乱的问题。下面分两部分解答你的疑问：

1. 关于flatMap的使用是否正确？ #

语法上它是合法的，但设计思路完全错了。flatMap的核心作用是把一个Observable的元素转换成多个Observable，然后合并这些Observable的输出（可能会打乱顺序）。但你用它来做串行的API调用，其实更适合用concatMap（能严格保证执行顺序），不过最核心的问题还是嵌套结构和全局变量。

2. 如何去掉全局变量，在链式调用中传递结果？ #

这里有两种优雅的实现方式，完全不需要全局变量：

方式一：串行调用+自动合并结果（推荐）

如果三个API是独立的，只需要按顺序调用并合并所有结果，可以用concat把三个请求串起来，再通过操作符自动合并：

private void requestWebResults(String query) {
    // 封装单个API请求的逻辑，避免重复代码
    Function<String, Observable<List<WebResult>>> createApiRequest = param -> 
        MainApplication.apiProvider.getApiProviderA.getWebResults(param)
            .subscribeOn(Schedulers.io())
            .map(response -> {
                // 空值安全处理，返回非空列表
                if (response.getData() != null && response.getData().getResults() != null) {
                    return response.getData().getResults();
                }
                return Collections.emptyList();
            });

    // 串行执行三个请求，合并所有结果
    Observable.concat(
            createApiRequest.apply("query1"),
            createApiRequest.apply("query2"),
            createApiRequest.apply("query3")
        )
        .flatMapIterable(results -> results) // 把每个列表拆成单个元素
        .toList() // 把所有元素合并成一个最终列表
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(new DisposableObserver<List<WebResult>>() {
            @Override
            public void onNext(List<WebResult> results) {
                // 这里直接拿到三个API的合并结果，放心使用
            }

            @Override
            public void onError(Throwable e) {
                // 记得处理错误，比如提示用户请求失败
            }

            @Override
            public void onComplete() {
            }
        });
}

方式二：逐步累积结果（适合需要依赖前序结果的场景）

如果后续请求需要用到前面的结果（比如第二个请求的参数依赖第一个请求的返回值），可以在flatMap中传递累积的列表：

private void requestWebResults(String query) {
    MainApplication.apiProvider.getApiProviderA.getWebResults("query1")
        .subscribeOn(Schedulers.io())
        // 第一个请求：初始化结果列表
        .map(response -> {
            List<WebResult> results = new ArrayList<>();
            if (response.getData() != null && response.getData().getResults() != null) {
                results.addAll(response.getData().getResults());
            }
            return results;
        })
        // 第二个请求：在已有列表中添加新结果
        .flatMap(currentResults -> 
            MainApplication.apiProvider.getApiProviderA.getWebResults("query2")
                .map(response -> {
                    if (response.getData() != null && response.getData().getResults() != null) {
                        currentResults.addAll(response.getData().getResults());
                    }
                    return currentResults;
                })
        )
        // 第三个请求：继续累积结果
        .flatMap(currentResults -> 
            MainApplication.apiProvider.getApiProviderA.getWebResults("query3")
                .map(response -> {
                    if (response.getData() != null && response.getData().getResults() != null) {
                        currentResults.addAll(response.getData().getResults());
                    }
                    return currentResults;
                })
        )
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(new DisposableObserver<List<WebResult>>() {
            @Override
            public void onNext(List<WebResult> results) {
                // 处理最终的合并结果
            }

            @Override
            public void onError(Throwable e) {
                // 错误处理逻辑
            }

            @Override
            public void onComplete() {
            }
        });
}

3. 原来的实现还有哪些问题？ #

• 嵌套结构可读性极差：多层flatMap嵌套后，逻辑变得混乱，后期改bug或者加新请求都会非常痛苦。
• 全局变量风险高：如果这个方法被多次调用，或者在多线程场景下，resultsList会被意外覆盖，导致数据错误。
• 错误处理缺失：任何一个API请求失败，整个链条都会直接进入onError，但你没有做任何处理，用户可能完全不知道请求失败了。

内容的提问来源于stack exchange，提问作者c0dehunter