SwiftUI Combine MVVM下cancellables数量持续升高是否正常？

数量持续上涨的核心原因 #

这种可取消项只增不减的情况完全不正常，本质是你对Combine订阅的生命周期管理出现了错位：

• 你在代码里把两类生命周期天差地别的订阅，全塞进了同一个全局cancellables集合：
  • 一类是和LoginViewModel同生命周期的长期订阅：也就是init方法中给authenticate这个PassthroughSubject绑定的sink，这个订阅从ViewModel初始化开始一直存活到ViewModel被销毁，存进全局集合是完全合理的。
  • 另一类是每次点击登录才生成的一次性、短生命周期订阅：也就是sink回调里嵌套发起的网络请求对应的订阅。每触发一次登录，这个网络订阅就会生成一个新的AnyCancellable实例，被直接存入全局集合。
• Set<AnyCancellable>本身没有自动清理已完成订阅的机制：只要可取消项被存入集合，集合就会一直持有它的强引用。哪怕对应的网络请求早就结束、订阅已经收到completion事件，这个实例也不会被自动移出集合。点一次登录多一个实例，自然集合元素数量会持续升高。

隐藏的额外问题 #

• 这种持续累积的可取消项属于轻度内存泄漏，长期运行会占用不必要的内存。
• 因为没有对请求做去重和取消逻辑，用户快速连续点击登录按钮时，会同时发起多个并行的网络认证请求，最终返回结果的时序不可控，容易出现登录状态错乱的问题。

具体修复方式 #

• 删掉冗余的PassthroughSubject中转逻辑
  你当前定义的authenticateSubject没有实际业务价值：按钮点击时会直接调用login()方法，完全不需要通过Subject把用户名密码转发给sink再触发网络请求，删掉这层中转能减少一个不需要维护的长期订阅。
• 对短生命周期的网络请求订阅做单独管理
  不要把一次性的网络请求订阅直接存进全局cancellables集合，单独为活跃的登录请求维护一个可取消项引用，示例代码如下：

  class LoginViewModel: ObservableObject {
      @Published var email: String = ""
      @Published var password: String = ""
      
      // 全局cancellables仅存放和ViewModel同生命周期的长期订阅
      var cancellables = Set<AnyCancellable>()
      // 单独存放当前正在进行的登录请求对应的可取消项
      private var activeLoginCancellable: AnyCancellable?
  
      func login() {
          // 发起新请求前先取消上一次未完成的请求，避免重复发起
          activeLoginCancellable = Webservice().authenticate(
              username: email,
              password: password
          )
          .receive(on: DispatchQueue.main)
          .sink(receiveCompletion: { [weak self] completion in
              // 请求结束（成功/失败/取消）后置空引用，自动释放可取消项
              self?.activeLoginCancellable = nil
          }, receiveValue: { token in
              // 处理登录成功后的逻辑
          })
      }
  }
  

• 尽量避免嵌套sink的写法
  写Combine链路时优先用flatMap这类操作符把多层逻辑串成单条链路，不要在sink的回调里再嵌套新的sink，从写法上减少遗漏短生命周期订阅管理的可能。

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