Swift 5.5引入了结构化并发与Actor模型，随之而来的Sendable协议成为编译器判断一个类型能否安全跨越并发域传递的核心依据。当这个检查延伸到协议的关联类型时，问题就变得微妙起来：编译器有时能自动推断关联类型满足Sendable，有时又必须由开发者显式写约束。理解这背后的推断规则，是写出既通过严格并发检查、又不过度限制泛型能力代码的关键。
Sendable协议的核心语义与基本推断规则
Sendable本身是一个标记协议，没有任何方法要求，它的价值完全由编译器在编译期静态检查体现。一个类型声明遵循Sendable，等于向编译器承诺：该类型的实例被多个并发域同时访问是安全的。编译器会根据类型的结构逐层验证这个承诺是否成立。
对于struct，编译器会检查所有存储属性是否本身满足Sendable。比如一个只包含Int、String、Double的结构体可以自动获得Sendable遵循；但只要有一个存储属性是可变的类实例或不遵循Sendable的闭包，推断就会失败。对于enum，编译器检查所有关联值；对于class，要求则严格得多：必须是final、所有存储属性必须是let且类型可Sendable，或者整个类标记为@unchecked Sendable由开发者自行担保线程安全。
看一个基础的例子：
// 编译器可以自动推断 Sendable：所有成员均可 Sendable
struct Coordinate: Sendable {
let x: Double
let y: Double
}
// 编译错误：var 属性的 class 无法安全跨线程
final class Counter: Sendable { // 报错：stored property 'value' is mutable
var value = 0
}
// 开发者自行担保：绕过编译器检查
final class LockedCounter: @unchecked Sendable {
private var value = 0
private let lock = NSLock()
func increment() {
lock.lock()
value += 1
lock.unlock()
}
}
这里需要特别注意@unchecked Sendable的代价：编译器完全不检查，一旦内部实现有线程安全隐患，运行期可能出现数据竞争且没有任何警告。它适合包裹内部自带锁机制的类型，比如NSLock保护的计数器，但不应该作为绕过报错的万能手段。
协议关联类型的Sendable约束：编译器推断的条件
当Sendable检查进入协议泛型语境，情况就复杂了。协议的关联类型本身是一个占位符，编译器在协议声明阶段并不知道它最终会被什么具体类型实现，因此默认情况下，关联类型不被假定满足Sendable。
编译器的推断规则大致如下：在协议声明中，如果关联类型本身声明了Sendable约束，例如associatedtype Element: Sendable，那么任何遵循该协议的类型，其Element对应的实际类型必须满足Sendable，编译器会在遵循处做检查。反过来，如果协议没有给关联类型加约束，但某个具体实现把Element确定为Int这样的内置Sendable类型，那么在该具体类型上做并发传递时，编译器可以基于具体化后的类型继续推断。
典型的分界线体现在异步序列上。AsyncSequence协议的Element关联类型就带有Sendable约束，这保证了在Task间传递序列元素的安全性：
protocol AsyncSequence<Element> {
associatedtype Element: Sendable
associatedtype AsyncIterator: AsyncIteratorProtocol
where AsyncIterator.Element == Element
func makeAsyncIterator() -> AsyncIterator
}
如果去掉这个Sendable约束，任何把AsyncSequence元素传出Actor隔离边界的代码都会失去静态保障。这说明关联类型上的Sendable约束并非可有可无的修饰，而是协议契约的一部分：它把并发安全要求从调用处前移到了协议定义处，让所有遵循者统一承担责任。
哪些场景必须显式声明Sendable约束
第一类必须显式声明的场景是：协议方法会在隐式并发上下文中使用关联类型。比如一个协议约定把元素投递到另一个Task，此时关联类型必须跨并发域，不写Sendable约束编译器直接报错：
protocol Emitter {
associatedtype Output
func emit(_ value: Output) async
// 编译器会提示：non-sendable type 'Output' crossed into
// a different concurrency domain via async call
}
// 正确写法：显式约束关联类型
protocol SafeEmitter {
associatedtype Output: Sendable
func emit(_ value: Output) async
}
第二类场景是泛型函数对参数做并发传递。Swift 5.7之后引入了sending相关的推断改进，但在严格并发检查模式下，泛型参数T只遵循某个协议时，编译器不会自动假定T: Sendable，即使协议的其他方法看起来线程安全。唯一的例外是隐式主Actor隔离等特殊语境。此时要么在函数签名上加where T: Sendable，要么让协议本身约束关联类型。
第三类是条件性Sendable。当泛型容器的Sendable性质取决于泛型参数时，标准写法是在类型声明处使用条件遵循：
struct Box<T>: Sendable where T: Sendable {
let content: T
}
这种写法让Box<Int>自动Sendable，而Box<某个非Sendable类>则不满足，编译器按具体实例化的参数逐个判断，做到了精确而非一刀切的约束。
常见报错排查与方案对比
遇到类似non-sendable type crossed into a different concurrency domain的报错时，建议按三步排查。第一步确认报错指向的具体类型是关联类型占位符还是具体类型：如果是占位符，问题出在协议缺少约束；如果是具体类型，检查它的存储结构。第二步检查是否误用@unchecked Sendable掩盖了真实问题，这类代码在严格检查升级后往往集中爆发。第三步评估约束应该加在协议层还是调用层：加在协议层会强制所有遵循者，调用层的where子句则更灵活但容易遗漏。
| 方案 | 约束强度 | 适用场景 | 主要风险 |
|---|---|---|---|
| 协议层关联类型加Sendable约束 | 强，所有遵循者受限 | 元素必然跨并行的协议 | 排除无法Sendable的合理实现 |
| 调用处where T: Sendable | 弱，逐点约束 | 只有部分方法需要传递 | 约束分散，维护成本高 |
| @unchecked Sendable | 无静态检查 | 内部有锁的封装类型 | 数据竞争风险完全自担 |
总体而言，Sendable约束的推断遵循一条清晰的逻辑链：编译器只能基于已知的类型结构做静态判断，关联类型在协议层面是未知数，所以涉及并发传递的关联类型必须显式声明约束。把这个约束写在协议定义处，通常比散落在各调用点更能表达协议的并发契约，也让代码在后续Swift版本收紧并发检查时保持稳定。
SwiftSendable协议关联类型约束修改时间：2026-09-06 02:12:43