Swift Concurrency落地之后，Sendable成为了绕不开的话题。枚举本身就是Swift里表达状态和数据载荷最自然的工具，一个带关联值的枚举既能描述“发生了什么”，又能顺带携带“发生时的数据”。但当一个枚举跨越Task边界、在不同Actor之间传递时，编译器会立刻追问：它携带的数据是否安全？这个问题看似简单，实际涉及合成规则、显式声明、非公开成员推断等一系列细节，稍有疏忽就会在并发检查严格的代码里收到一串编译警告甚至错误。
Sendable枚举的自动合成规则：编译器什么时候放行
先看最基础的问题：一个枚举在什么条件下会被自动认定为Sendable。Swift编译器的规则其实很直接——如果枚举的所有关联值类型本身都是Sendable，并且枚举不是public或者open的（或者虽然公开但处于同一个编译单元且启用了相应推断），编译器就会自动为它合成Sendable一致性，不需要你写任何代码。
来看一个典型例子：
// 内部枚举，关联值全是值类型，自动满足Sendable
enum DownloadState {
case idle
case downloading(progress: Double)
case completed(data: Data)
case failed(error: DownloadError)
}
// DownloadError也遵循Error和Sendable
enum DownloadError: Error, Sendable {
case network(timeout: TimeInterval)
case diskFull
}Data、Double、TimeInterval都是标准库里的不可变语义值类型，天然满足Sendable，所以DownloadState会被静默合成一致性。但把修饰符改成public，情况就变了。出于库的二进制稳定性考虑，跨模块边界的公开类型如果依赖编译器合成的Sendable，未来内部实现一旦引入不可发送类型就会破坏API契约，因此Swift要求公开类型显式声明Sendable。这就是很多开发者升级到Swift 6语言模式后突然冒出大量警告的原因之一。
另一个容易踩坑的点是关联值是引用类型的场景。比如关联值是NSManagedObject、UIViewController这类非Sendable的类实例，编译器不仅不会合成，还会在你手动声明时直接报错。此时的解决思路只有两条：要么把关联值改成值类型快照，要么通过@unchecked Sendable自己为线程安全背书——后者意味着你向编译器承诺内部已经做了同步保护，风险自担。
跨Task与Actor传递携带数据的枚举
理解了合成规则，接下来看实际并发场景中的使用。在Swift的并发模型里，数据竞争被隔离机制阻断：非Sendable的值不允许跨越并发域传递。枚举作为状态消息在Task之间流转是非常常见的模式，例如一个下载管理器把DownloadState通过AsyncStream发给监听方：
func observeStates() -> AsyncStream<DownloadState> {
AsyncStream { continuation in
let task = Task {
for await state in manager.states {
continuation.yield(state)
}
continuation.finish()
}
continuation.onTermination = { _ in
task.cancel()
}
}
}这里DownloadState在产生它的Task和消费它的上下文之间穿梭，只要它是Sendable的，编译器就允许这种传递且不需要任何运行时开销——Sendable完全是编译期约束，不产生动态检查。这也是它比传统的锁方案优雅的地方：安全性在编译阶段就被验证，而不是等到运行时崩溃才暴露。
需要注意的是类类型关联值即使加了锁也不能随意标记@unchecked Sendable。正确的做法通常是先做一次“值化”，把引用类型中需要的字段提取成结构体。比如你有一个非Sendable的数据库连接对象，不要把整个对象塞进枚举关联值，而是把查询结果转换成[Row]这样的值类型数组再传递。这个“在边界处做快照”的思想是并发安全传递枚举的核心实践。
另外，@preconcurrency修饰符在迁移旧代码时很有用。它允许你暂时把一个尚未适配Sendable的第三方类型当作Sendable使用，编译器会降级为警告而不是错误，给渐进式迁移留出空间。但最终目标仍然是彻底消除这种妥协。
关联值的模式匹配：switch、值绑定与where守卫
枚举到了消费端，就要靠模式匹配来解构关联值。最基本的写法是switch配合值绑定：
func handleMessage(_ message: Message) {
switch message {
case .text(let content):
print("收到文本: \(content)")
case .image(let data, let format):
print("收到图片，格式\(format)，大小\(data.count)")
case .location(let lat, let lon) where abs(lat) <= 90 && abs(lon) <= 180:
print("合法坐标 (\(lat), \(lon))")
case .location:
print("坐标非法，丢弃")
@unknown default:
break
}
}
enum Message: Sendable {
case text(String)
case image(Data, format: String)
case location(latitude: Double, longitude: Double)
}几个细节值得展开。第一，where守卫可以对绑定的关联值做条件过滤，同一个case可以出现多次，匹配顺序自上而下，这比在case内部写if判断更清晰。第二，当只需要部分关联值时，可以用下划线忽略其余部分，写成case .image(let data, _)，减少不必要的绑定。第三，如果枚举可能在未来扩展（尤其是跨模块的公开枚举），务必加上@unknown default，它和普通default的区别在于编译器会在未来新增case时给你提示，保证二进制兼容。
在并发上下文中，模式匹配还有一层价值：解构发生之后，绑定的局部常量通常是值语义的，天然可以在当前执行域内自由使用，不会再引发跨域传递问题。反之，如果你把匹配出来的引用类型关联值直接抛给另一个Task，就要重新过一遍Sendable检查。可以配合guard case做单case匹配，这在状态机轮询里很实用：
// 从 AsyncStream 中只关心进度更新
for await state in stream {
guard case .downloading(let progress) = state else { continue }
viewModel.progress = progress
}这种写法避免了为单一case写完整switch，代码更紧凑。不过要提醒一点，guard case失败时走else分支，逻辑上等价于“不是这个case就跳过”，滥用会让流程难以追踪，复杂分支还是老老实实用switch。
典型陷阱与最佳实践总结
第一类陷阱是隐式捕获导致的Sendable违规。在Task { }闭包里捕获了不可发送的关联值对象，即使枚举本身声明了@unchecked Sendable，捕获动作本身仍可能触发严格并发检查。解决办法是尽量在闭包外完成解构，只把需要的值类型数据捕获进去。
第二类陷阱是把@unchecked Sendable当万能补丁。这个修饰符关闭的是编译器检查，不是数据竞争本身。如果内部没有任何锁或串行队列保护，跨线程访问依然会崩溃或产生脏数据。规范的做法是只在外部框架类型且确认其内部线程安全（比如Apple文档明确说明的类）时使用，并在注释中写明依据。
总结几条实践准则：优先使用值类型作为关联值，让编译器自动合成Sendable；公开API中的枚举显式声明Sendable，不依赖合成行为；在并发边界处把引用类型转换为值快照；模式匹配时合理使用where守卫和@unknown default保持分支完备。做到这几点，携带数据的枚举就能在Swift并发世界里既安全又优雅地流转。