Swift主线程Dispatch串行任务异常：MethodB未触发求助

嘿，我完全懂你碰到的麻烦——你的代码里有个典型的异步逻辑顺序错误：你在serialQueue.async的闭包里调用methodA之后，立刻就去检查count并判断是否执行methodB，但methodA是带回调的异步方法啊！这时候methodA的回调还没触发，count根本没机会更新，所以count == 1的条件永远不成立，methodB自然不会执行。

调整后的正确代码 #

你需要把检查count和执行methodB的逻辑放到methodA的回调闭包里面，确保只有等methodA完全执行完成（不管成功还是失败），才会进行后续判断：

let serialQueue = DispatchQueue.main
var count = 0

serialQueue.async {
    // 先执行主线程的methodA
    TestHelper().methodA(title: title, art: art) { url in
        if let validUrl = url {
            // methodA成功，直接返回结果
            completion(validUrl)
        } else {
            // methodA失败，更新count
            count += 1
            // 现在才检查count，触发methodB
            if count == 1 {
                TestHelper().methodB(title: title, art: art) { url in
                    if let validUrl = url {
                        // methodB成功，返回结果
                        completion(validUrl)
                    } else {
                        // methodB也失败，更新count并返回nil（或者根据你的需求处理）
                        count += 1
                        completion(nil)
                    }
                }
            }
        }
        print(count) // 现在打印的是methodA执行后的最新count值
    }
}

关键逻辑说明 #

1. 异步回调的顺序问题：异步方法的回调是在未来某个时间点才会执行的，所以不能在调用异步方法后立刻去依赖它的执行结果（比如count的变化），必须把后续逻辑放到回调闭包内。
2. 主线程保证：因为你已经把整个逻辑放到DispatchQueue.main.async里，methodA的调用是在主线程的，如果methodA的回调本身也是在主线程触发（大部分UI相关API的回调都会在主线程），那后续的count更新和methodB调用也自然在主线程，符合你的需求。如果methodA的回调不在主线程，你可以在回调里再嵌套一层DispatchQueue.main.async来确保UI安全。
3. 失败后的处理：我在代码里补充了methodB也失败的情况，你可以根据实际需求调整（比如重试、返回错误信息等），避免调用者一直等待completion触发。

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