为何多数SwiftUI类型（如Color、Text）不支持Sendable？

• SwiftUI运行模型的限制：这些类型本质是「渲染描述符」，而非直接的UI实例。它们的内部逻辑依赖当前视图环境（比如颜色方案、字体上下文），而SwiftUI的渲染流程严格绑定主线程，框架设计时就没考虑让这些类型跨线程传递——跨线程传递它们既无必要，还可能触发渲染异常。
• 框架封装的设计选择：Apple通过不标记Sendable，引导开发者遵循SwiftUI的并发规范：所有视图相关的创建、更新操作都应在主线程完成，不需要把Color、Text这类视图元素拿到后台线程处理。
• 内部实现的灵活性：这些类型的私有底层可能包含非Sendable的兼容对象（比如Objective-C层面的依赖），不标记Sendable能让Apple在后续版本中自由调整实现，不受Sendable协议的约束。

如果你满足以下两个前提，标记@unchecked Sendable是完全安全的：

1. Color实例在主线程创建，且不会在后台线程被修改或解析；
2. Test结构体跨线程传递后，Color的使用场景依然是主线程的SwiftUI渲染流程。

示例代码：

struct Test: @unchecked Sendable {
  let color: Color
}

更稳妥的替代方案 #

如果想完全避免@unchecked Sendable，可以将Color转换为线程安全的原始值存储，在主线程按需重建Color：

struct Test: Sendable {
  // 存储RGB+Alpha数值，均为Sendable兼容类型
  let rgb: (red: Double, green: Double, blue: Double, alpha: Double)
  
  // 在主线程访问时生成Color
  var color: Color {
    Color(red: rgb.red, green: rgb.green, blue: rgb.blue, opacity: rgb.alpha)
  }
}

这种方式既符合Sendable要求，也完全遵循SwiftUI的主线程渲染原则，没有任何并发风险。

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