RxSwift重试与错误处理最佳实践及混合重试流设计咨询

嘿，这两个问题都是RxSwift实际开发中很常见的痛点，我来给你拆解一下解决方案：

一、解决Result类型无法触发重试的问题 #

首先得明确：RxSwift的retry()系列操作符确实只监听序列的onError事件——如果把业务错误封装在Result里放到onNext，重试逻辑自然不会被触发。而你提到的“仅将致命错误传递至onError”的最佳实践，其实是有前提的：这里的致命错误指的是完全无法恢复、不需要重试的错误（比如用户权限不足、设备彻底无网络），而可重试的业务错误，其实应该被当作onError抛出，这样才能让重试机制生效。

推荐方案：区分错误类型，合理发送onError #

这是最贴合Rx设计理念的方式，既遵循最佳实践，又能触发重试：

// 假设你的API返回Result<Data, APIError>
func fetchData() -> Observable<Result<Data, APIError>> { ... }

// 转换序列：将可重试错误转为onError，成功数据直接传递，致命错误也转为onError
fetchData()
    .flatMap { result -> Observable<Data> in
        switch result {
        case .success(let data):
            return .just(data)
        case .failure(let error):
            if error.isRetryable { // 自定义判断：比如后端返回的"请求超时""服务繁忙"等
                return .error(error)
            } else {
                // 不可重试的业务错误（比如参数错误），可以包装成致命错误抛出
                return .error(CustomFatalError.wrap(error))
            }
        }
    }
    .retry(3) // 现在就能正常触发重试了

备选方案：自定义针对Result的重试操作符 #

如果因为特殊业务约束，确实不能把可重试错误放到onError，可以自己写一个监听onNext中Result错误的重试操作符：

extension ObservableType where Element == Result<Data, APIError> {
    func retryOnRetryableError(maxAttempts: Int) -> Observable<Element> {
        return self.flatMapLatest { result -> Observable<Element> in
            switch result {
            case .success:
                return .just(result)
            case .failure(let error):
                if error.isRetryable && maxAttempts > 0 {
                    // 递归调用，减少重试次数
                    return self.retryOnRetryableError(maxAttempts: maxAttempts - 1)
                } else {
                    return .just(result)
                }
            }
        }
    }
}

不过这种方式会让序列逻辑变得复杂，可读性下降，除非必要，否则优先选第一种方案。

二、全局与本地重试混合的流程设计（以iOS收据验证为例） #

你提到的收据验证流程有状态依赖（是否是第二次尝试、是否强制从Apple服务器获取），用Rx的话完全不需要维护全局变量——我们可以通过状态流转的Observable来管理所有状态，把状态作为序列的一部分传递，这样既符合响应式理念，又能避免全局变量带来的状态混乱。

第一步：定义流程状态 #

先把流程中可能的状态枚举出来，清晰梳理每个状态的行为：

enum ReceiptVerificationState {
    case initial // 初始状态：先尝试本地获取收据
    case retry(forceFetch: Bool) // 重试状态：标记是否需要强制从Apple服务器获取
    case completed // 流程完成
    case failed // 流程失败
}

// 自定义流程中的错误类型
enum ReceiptError: Error {
    case localFetchFailed
    case appleFetchFailed
    case backendVerificationFailed(retryable: Bool)
}

第二步：构建响应式流程 #

用scan操作符来维护状态流转，把单次验证逻辑和状态管理分离：

func verifyReceipt() -> Observable<Void> {
    // 初始状态：只发送一次initial
    let initialState = Observable.just(ReceiptVerificationState.initial)
    
    return initialState
        // 用scan维护当前状态，accumulator是当前的流程状态
        .scan(into: ReceiptVerificationState.initial) { currentState, nextState in
            currentState = nextState
        }
        // 根据当前状态执行对应的流程
        .flatMapLatest { currentState -> Observable<ReceiptVerificationState> in
            switch currentState {
            case .initial:
                return self.attemptSingleVerification(forceFetch: false)
            case .retry(let forceFetch):
                return self.attemptSingleVerification(forceFetch: forceFetch)
            case .completed, .failed:
                return .empty() // 状态为完成/失败时，终止序列
            }
        }
        // 当状态为completed或failed时，停止监听序列
        .take(until: { $0 == .completed || $0 == .failed })
        // 只保留完成状态的事件，转换为Void输出
        .filter { $0 == .completed }
        .map { _ in }
}

// 单次验证的具体逻辑：根据forceFetch决定获取收据的方式
private func attemptSingleVerification(forceFetch: Bool) -> Observable<ReceiptVerificationState> {
    // 选择收据获取方式：forceFetch为true时直接从Apple获取，否则先尝试本地
    let fetchReceiptObservable: Observable<Data>
    if forceFetch {
        fetchReceiptObservable = self.fetchReceiptFromApple()
    } else {
        fetchReceiptObservable = self.fetchReceiptLocally()
            .catch { _ in self.fetchReceiptFromApple() } // 本地失败则尝试Apple
    }
    
    return fetchReceiptObservable
        // 将收据发送到后端验证
        .flatMap { receiptData in
            self.sendToBackend(receiptData)
        }
        // 验证成功，返回completed状态
        .map { _ in ReceiptVerificationState.completed }
        // 处理错误，决定下一步状态
        .catch { error -> Observable<ReceiptVerificationState> in
            guard let receiptError = error as? ReceiptError else {
                return .just(.failed)
            }
            
            switch receiptError {
            case .backendVerificationFailed(let retryable):
                if retryable {
                    // 仅重试一次，且强制从Apple获取新收据
                    return .just(.retry(forceFetch: true))
                } else {
                    return .just(.failed)
                }
            case .localFetchFailed, .appleFetchFailed:
                // 收据获取失败，直接终止流程
                return .just(.failed)
            }
        }
}

// 模拟各个子操作（实际开发中替换为真实逻辑）
private func fetchReceiptLocally() -> Observable<Data> {
    // 本地获取收据逻辑，失败则throw ReceiptError.localFetchFailed
}

private func fetchReceiptFromApple() -> Observable<Data> {
    // 向Apple服务器请求收据逻辑，失败则throw ReceiptError.appleFetchFailed
}

private func sendToBackend(_ receipt: Data) -> Observable<Void> {
    // 发送到后端验证逻辑，失败则throw ReceiptError.backendVerificationFailed(retryable: Bool)
}

设计思路说明 #

1. 用状态序列替代全局变量：所有状态（是否重试、是否强制获取）都由scan操作符维护在序列内部，不需要额外的全局变量，避免了状态混乱和竞态问题。
2. 职责分离：attemptSingleVerification负责单次验证的具体逻辑，上层的scan和flatMapLatest负责状态流转，代码结构清晰，易于维护和扩展。
3. 精确控制重试次数：因为要求仅重试一次，所以当后端返回可重试错误时，只发送一次.retry(forceFetch: true)的状态，后续如果再次失败，直接进入.failed状态，终止流程。

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