Swift & Combine异步函数最佳实践：主线程交互问题

问题场景 #

正在将Swift应用迁移至Combine框架与async/await语法，实现加载用户信息的异步函数时，遇到了主线程发布变更的警告。

相关代码 #

AccountManager实现：

class AccountManager {

    static func fetchOrLoadUser() async throws -> AppUser {
        if let user = AppUser.current.value {
            return user
        }
    
        let syncUser = try await loadUser()
        let user = try AppUser(syncUser: syncUser)
    
        AppUser.current.value = user // [警告]: "Publishing changes from background threads is not allowed"
        return user
    }
}

AppUser定义：

class AppUser {

    static var current = CurrentValueSubject<AppUser?,Never>(nil)

    // ...
}

注：选择CurrentValueSubject是因为它支持（1）同步读取值，（2）订阅值变化。

针对标记行的警告，我考虑了三种解决方案，同时有以下疑问：

解决方案分析 #

1. 为AccountManager类添加@MainActor标记 #

疑问：异步函数主要工作是等待网络结果，直接在主线程运行所有逻辑会不会有性能问题？

解答：
不会有明显性能问题。async/await机制下，try await loadUser()会自动让出线程，网络请求的等待过程不会阻塞主线程；只有请求完成后的轻量逻辑（比如解析用户对象、赋值current.value）会在主线程执行，这部分操作对UI响应几乎没有影响。

这种方案完全符合Swift并发模型的设计，@MainActor能确保所有与Combine发布、UI相关的操作都在主线程执行，代码简洁且安全，是优先推荐的方案。修改后代码示例：

@MainActor
class AccountManager {

    static func fetchOrLoadUser() async throws -> AppUser {
        // 原有逻辑保持不变
    }
}

2. 将报错行包裹在DispatchQueue.main.sync中 #

疑问：这是否为合理方案？会不会导致死锁？

解答：
这不是合理方案，存在明确的死锁风险。如果当前代码已经在主线程执行时调用sync，会导致主线程等待自身完成任务，直接触发死锁。此外，在async/await的结构化并发模型中混用GCD，会破坏并发逻辑的一致性，增加代码维护难度。

3. 使用DispatchGroup的enter()、leave()和wait()方法 #

疑问：该方案和方案2是否有差异？代码量更多，倾向简洁方案。

解答：
本质上和方案2没有核心差异，都是基于GCD的线程调度逻辑，同样会破坏async/await的结构化并发规范。而且代码更繁琐，没有额外优势，完全不推荐使用。

总结 #

优先选择方案1（@MainActor标记），既符合Swift并发设计规范，代码简洁易维护，又能安全地在主线程发布Combine的Subject变更，同时不会影响网络请求的性能。

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