Swift Combine中Set<AnyCancellable>工作机制及订阅未自动取消问题

我定义了一个带有可释放Set的ViewModel：

class ViewModel {
    private var disposables = Set<AnyCancellable>()
    func sync() {
        repo.syncObjects()
            .handleEvents(receiveCancel: { print("Synced objects: CANCELED!") })
            .sink(receiveCompletion: { completion in
                switch completion {
                case .failure(let error):
                    print("Synced objects: \(error)")
                case .finished:
                    print("Synced objects: finished")
                }
            }) { objects in
                print("Synced objects: \(objects)")
            }.store(in: &disposables)
    }
    deinit { print("ViewModel deinit") }
}

我在SwiftUI视图的onAppear中调用sync()方法，快速切换页面后，ARC已经释放了ViewModel（deinit日志已经打印），但订阅似乎还存活，没有自动取消。它仍然会从网络获取数据并保存到Core Data，打印对应的日志，旧请求需要好几秒才完成。

请问是否需要手动取消AnyCancellable？它难道不该自动取消吗？

这个问题是Combine订阅生命周期里的常见误区，我给你拆解清楚：

首先，AnyCancellable自动取消的前提是它和持有对象的生命周期绑定——当你的ViewModel被释放时，disposables这个Set<AnyCancellable>也会被销毁，里面的所有AnyCancellable理论上会自动调用cancel()方法。那为什么你的场景里没生效？

可能的原因： #

• 订阅链存在隐式强引用循环
  你可以检查下repo.syncObjects()返回的Publisher，或者sink闭包内部有没有捕获self的强引用？比如如果在闭包里隐式用了self（比如调用ViewModel的其他方法），而Publisher又持有这个闭包，就可能形成循环引用。虽然你给出的代码里sink只是打印，但最好确认下repo的持有关系，以及Publisher内部有没有偷偷捕获self。
• 网络请求未响应Combine的取消信号
  有些自定义或第三方的网络Combine封装，可能没把Combine的取消信号传递给底层网络任务。也就是说，AnyCancellable调用cancel()后，只是终止了订阅的回调，但实际的网络请求还在后台跑，直到完成。

解决方案： #

1. 手动触发取消（保险做法）
   虽然理论上集合会自动销毁，但手动在deinit里清空集合能强制触发所有订阅的取消，避免意外：

   deinit {
       disposables.removeAll() // 强制调用所有AnyCancellable的cancel方法
       print("ViewModel deinit")
   }
   

2. 排查并修复强引用
   用Xcode的内存图工具检查ViewModel是否真的被完全释放，另外如果闭包里需要引用self，尽量用弱引用捕获：

   .sink(receiveCompletion: { [weak self] completion in
       // 处理完成逻辑，使用self?.xxx访问ViewModel成员
   }) { [weak self] objects in
       // 处理结果逻辑
   }
   

3. 确保Publisher正确响应取消
   如果你是自定义的网络Publisher，要确保在收到取消信号时终止底层任务，比如URLSession的data task：

   func syncObjects() -> AnyPublisher<[Object], Error> {
       let task = URLSession.shared.dataTaskPublisher(for: url)
       // ...数据处理逻辑
       .handleEvents(receiveCancel: {
           task.cancel() // 手动取消底层网络任务
       })
       .eraseToAnyPublisher()
   }
   

总结一下：AnyCancellable的自动取消是设计预期，但实际场景中可能因为强引用、Publisher实现缺陷失效。手动在deinit清空集合是简单有效的补救方式，排查订阅链的引用关系和Publisher的取消逻辑才是根本解决办法。

内容的提问来源于stack exchange，提问作者Michał Ziobro