如何解决Xcode严格并发检查下的‘捕获非Sendable类型self’警告？

问题根源 #

警告Capture of 'self' with non-sendable type 'ViewA' in a @Sendable closure的本质是：

• ViewA包含非Sendable类型的属性（unsendableItem对应的UnsendableClass未遵守Sendable协议），导致ViewA本身不是Sendable类型；
• 在@Sendable闭包（navigateTo的completion参数因navigateTo标记了@MainActor，会被隐式推断为@Sendable）中，通过didNavigate?()隐式捕获了self，违反Swift并发安全规则。

以下是几种高效解决方法，可根据场景选择：

方法一：让相关类型合规遵守Sendable协议（最规范） #

从根源解决问题，让所有涉及的类型符合并发安全要求：

1. 让UnsendableClass遵守Sendable：

   // 若类不可继承，直接标记final并遵守Sendable
   final class UnsendableClass: Sendable {
       var item: Any?
   }
   
   // 若类需要继承，使用@unchecked Sendable（需自行保证并发安全）
   // class UnsendableClass: @unchecked Sendable {
   //     var item: Any?
   // }
   

2. 将didNavigate闭包标记为@Sendable：

   struct ViewA: View {
       var unsendableItem: UnsendableClass?
       // 显式标记闭包为@Sendable
       var didNavigate: (@Sendable () -> Void)? = nil
       
       // ... 其余代码不变
   }
   

此时ViewA会自动成为Sendable类型，闭包中捕获self不再触发警告。

方法二：局部捕获闭包变量，避免捕获self（最灵活） #

如果无法修改UnsendableClass或didNavigate的类型，可通过局部变量存储didNavigate，避免闭包隐式捕获self：

func buttonAction() {
    // 将didNavigate存为局部变量，切断与self的关联
    let completionHandler = didNavigate
    Task { @MainActor in
        Navigation.shared.navigateTo("new") {
             completionHandler?()
        }
    }
}

这种方式无需修改任何类型定义，仅调整变量捕获逻辑即可规避警告，适合快速修复且不破坏原有结构的场景。

方法三：标记ViewA为@unchecked Sendable（兜底方案） #

若上述两种方法都无法实施（比如无法修改依赖的第三方类型），可显式标记ViewA为@unchecked Sendable，告知编译器自行负责其并发安全：

// 标记为@unchecked Sendable，需确保ViewA的属性不会在多线程中被不安全访问
struct ViewA: View, @unchecked Sendable {
    var unsendableItem: UnsendableClass?
    var didNavigate: (() -> Void)? = nil
    
    // ... 其余代码不变
}

⚠️ 注意：此方法仅作为兜底，使用时必须确保ViewA的所有属性在并发场景下不会出现数据竞争或不安全访问。

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