Swift 的 Sendable 标记协议本身不强制任何实现，但它在并发边界的检查中却异常严格。AsyncSequence 在跨越 Task 或 actor 隔离域时，编译器不仅要确认序列类型是 Sendable，还会检查迭代器以及元素类型是否满足传递安全。如果只在参数位置写一个 AsyncSequence，而没有用协议组合把 Sendable 一并约束进去，运行时可能不会立刻出错，但类型系统已经失去了对数据竞争的保护。本文会把协议组合的约束方式拆开，并演示在 for try await 迭代中如何构建既灵活又安全的泛型函数。

如果把 Sendable 和 AsyncSequence 分开理解，容易忽略二者在迭代链路中的耦合关系。异步序列的每一次推进都可能从一个执行上下文跳到另一个执行上下文，这意味着序列、迭代器、元素都会被编译器纳入并发安全检查。下面先梳理约束边界，再通过具体代码说明如何让类型系统替你守住安全底线。

先厘清 Sendable 与协议组合的约束边界

Sendable 协议不要求实现任何方法或属性，它的作用是向编译器声明某个类型的值可以安全地在并发域之间传递。结构体和枚举会由编译器自动推导 Sendable，条件是所有存储属性都满足 Sendable。类需要显式遵守，并且要么是 final class 且属性安全，要么使用 @unchecked Sendable 自己承担检查责任。AsyncSequence 则是描述异步序列的协议，它定义了一个关联类型 Element 和一个返回异步迭代器的 makeAsyncIterator 方法。

协议组合写作 AsyncSequence & Sendable，表示一个类型必须同时满足这两个协议。这看起来只是两个约束的叠加，但在实际编译中它不是简单的求交集。因为 AsyncSequence 带有关联类型，组合后的约束还隐含了对 Element 和迭代器类型的进一步要求。如果直接在参数中使用裸的 AsyncSequence，编译器只知道你可以异步迭代，却不知道序列本身能否跨并发域。只有加入 Sendable 后，类型检查器才会把序列视作并发安全的载体。这里需要特别区分 some 和 any 的用法：前者保留具体类型，后者擦除为 existential，各有不同的约束表现。

换句话说，协议组合在这里的核心价值并不是语法糖，而是让编译器在编译期就获得足够的类型信息。它让序列的 Sendable 属性不再依赖调用方的自觉，而成为 API 边界上的强制约束。下面会看到，当序列进入 actor 或 Task 的隔离域时，这一点会直接决定能否通过并发检查。

AsyncSequence 迭代时编译器在检查什么

for try await 迭代一个 AsyncSequence 时，编译器实际上调用了 makeAsyncIterator 创建迭代器，然后反复调用迭代器的 next 方法。这个过程中涉及三个可能需要跨并发域的类型：序列本身、迭代器、以及每次 next 返回的 Element。很多人只注意到序列类型要 Sendable，却忽略了迭代器也需要 Sendable。如果序列遵守了 Sendable，但迭代器没有显式标记，编译器在 actor 隔离域中使用时仍然会拒绝。

举一个典型场景：你有一个 actor，内部维护一个值数组，希望通过一个参数接收外部传入的 AsyncSequence 并迭代收集。如果函数签名写成 func collect(_ sequence: some AsyncSequence)，当你在 actor 方法里写 for try await 时，编译器会提示非 Sendable 类型不能跨 actor 隔离。原因是异步迭代会在多个任务之间挂起和恢复，迭代器状态必须能够安全地从一个执行上下文传递到另一个。如果迭代器内部含有引用类型或非 Sendable 存储，就可能产生数据竞争。

因此，要真正通过检查，至少需要两个层面的约束：序列类型遵守 AsyncSequence & Sendable，并且 S.Element 也约束为 Sendable。有些实现里迭代器本身就是序列的嵌套类型，只要序列声明 Sendable，迭代器往往也会自动获得 Sendable，但这不是绝对保证。显式写出约束会让 API 的意图更清楚，也能避免后续重构时破坏并发安全。

用泛型约束写出安全的迭代函数

最稳妥的写法是在泛型参数上同时声明 AsyncSequence 和 Sendable，并为元素追加 Sendable 约束。这样函数内部可以安全使用 for try await，调用方传入的序列必须完全满足并发要求。下面先定义一个可用的异步序列，它同时遵守 AsyncSequence 和 Sendable，元素类型为 Int。

struct NumberStream: AsyncSequence, Sendable {
    typealias Element = Int
    struct AsyncIterator: AsyncIteratorProtocol, Sendable {
        var current = 0
        let max: Int
        mutating func next() async throws -> Int? {
            guard current < max else { return nil }
            defer { current += 1 }
            return current
        }
    }
    func makeAsyncIterator() -> AsyncIterator {
        AsyncIterator(current: 0, max: 100)
    }
}

NumberStream 的结构体只包含 Int 属性，编译器可以自动推导 Sendable。嵌套的 AsyncIterator 同样声明为 Sendable，这样迭代器在挂起和恢复时可以安全传递。下面是一个接收任意满足条件的序列的泛型函数，它把协议组合直接放进约束列表。

func consume<S>(_ sequence: S) async throws where S: AsyncSequence & Sendable, S.Element: Sendable {
    for try await element in sequence {
        print(element)
    }
}

这里的 S: AsyncSequence & Sendable 就是协议组合约束。它限定了 S 必须同时满足异步序列和 Sendable。后续的 S.Element: Sendable 进一步保证迭代出来的值可以被安全处理。调用 consume(NumberStream()) 时，编译器会验证所有条件，如果 NumberStream 没有声明 Sendable，或者元素不是 Sendable，编译就会失败。这样就把并发安全检查从运行时移到了编译期。

也可以写成 unstructured existential 形式，例如 let sequence: any AsyncSequence<Int> & Sendable = NumberStream()。这种写法在需要存储异构序列时有用，但它会擦掉具体类型，迭代时可能存在性能开销。对于大多数只需要遍历的场景，泛型约束方式更利于内联和优化。

常见误区和类型安全验证

一个常见误区是以为给序列加上 @unchecked Sendable 就能解决所有编译器报错。@unchecked Sendable 确实会关闭编译器检查，但它是把安全责任全部推给开发者。AsyncSequence 的迭代器内部如果包含可变引用、锁或其他非 Sendable 状态，绕过检查后可能在并发执行时出现不可预期的数据竞争。除非你已经通过锁或 actor 等机制保证了内部状态的线程安全，否则不要轻易使用这个注解。

另一个容易忽略的地方是元素类型。即使序列本身满足 Sendable，如果 Element 是一个非 Sendable 的 class，迭代结果进入 actor 或 Task 后同样会被编译器拦截。所以约束中写上 S.Element: Sendable 并不是冗余，而是类型安全链条上的关键一环。可以把它理解为：序列安全、迭代器安全、元素安全，三者缺一不可。有的开发者会尝试把序列定义为 some AsyncSequence & Sendable，但这样仍然缺少元素约束，最好显式补上 where 条件。

验证方式也很直接：在 Xcode 中开启严格并发检查，将 consume 函数放入一个 actor 方法内，然后传入一个故意不遵守 Sendable 的序列，编译器会给出明确错误。再删掉 S.Element: Sendable 观察元素约束缺失时的报错，就能直观理解协议组合在 AsyncSequence 迭代中的实际作用。通过这种小实验，API 设计者可以更清楚地知道每个约束分别拦截了哪一类并发风险。

最后，如果多个函数都需要这样的约束，可以把常用的协议组合抽成一个类型别名，但要留意 AsyncSequence 的关联类型是否已经指定。例如 typealias SendableIntSequence = any AsyncSequence<Int> & Sendable 可以作为参数类型使用，但它不适合直接放在泛型约束的冒号后面。推荐的做法仍然是在泛型 where 中写清楚三个约束，这样可读性和编译诊断都更好。