结构体使用回调的最佳实践：解决闭包捕获可变self参数报错

嘿，这个问题我之前帮不少开发者捋清楚过，咱们一步步拆解来看：

首先，你遇到的「Closure cannot implicitly capture a mutating self parameter」错误，核心原因是结构体是值类型——当你在mutating方法里用异步回调时，闭包会试图捕获当前的self，但值类型的self是可变的副本，Swift为了避免数据不一致（比如闭包修改副本时原实例已经变了），直接禁止了这种隐式捕获。

要不要把ViewModel改成类？还是有结构体的方案？ #

这得看你的场景，但先给你两种选择的细节：

1. 坚持用结构体的可行方案（局限性大）

如果一定要用结构体，只有两种勉强可行的思路，但都有明显短板：

• 显式捕获可变副本：在闭包的捕获列表里声明[var self = self]，这样闭包里的self是一个可变的副本，但注意——你修改的只是这个副本，原结构体实例的pictures不会自动更新。这种方式只适合不需要原实例同步状态的场景，或者你得手动把副本的状态同步回去，非常麻烦：

  struct CatViewModel {
      var pictures: [String] = []
      
      mutating func fetchPictures(completion: @escaping () -> Void) {
          APIClient.fetch { [var self = self] catPictures in
              self.pictures = catPictures
              completion()
              // 这里改的是副本，原实例完全没变化
          }
      }
  }
  

• 非逃逸闭包场景：如果你的回调不是异步的（非逃逸闭包），可以直接在mutating方法里用self，但这显然不符合你异步获取图片的需求。

说白了，结构体天生不适合处理「异步回调更新自身状态」的场景，因为值类型的副本特性会让状态同步变得异常复杂。

2. 改成类（更推荐，符合Swift设计意图）

把ViewModel改成类是更直接的解决方案，因为类是引用类型——闭包捕获的是实例的引用，修改的是同一个实例的属性，完全没有副本问题。代码也更简洁，还能顺便处理循环引用：

class CatViewModel {
    var pictures: [String] = []
    
    func fetchPictures() {
        APIClient.fetch { [weak self] catPictures in
            self?.pictures = catPictures
        }
    }
}

这里用[weak self]是为了避免APIClient持有闭包、闭包持有ViewModel导致的循环引用，这是类使用逃逸闭包的最佳实践。

关于DispatchQueue.main.async的使用 #

要不要加这个，完全看你的回调执行线程：

• 如果你的APIClient是做网络请求/后台解析这类操作，回调大概率在后台线程执行，而UI更新必须在主线程，所以一定要加DispatchQueue.main.async把属性更新切到主线程：

  func fetchPictures() {
      APIClient.fetch { [weak self] catPictures in
          DispatchQueue.main.async {
              self?.pictures = catPictures
          }
      }
  }
  

• 如果回调本身已经在主线程（比如本地缓存读取的同步回调），那就没必要多此一举。

总结 #

如果你的ViewModel需要处理异步回调并更新状态，强烈建议改成类——结构体在这里的局限性太大，会给你后续的状态维护带来很多坑。类的方案不仅更简洁，也更符合Swift对于引用类型处理共享状态的设计思路。

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