Swift 协议带有关联类型 (PATs) 或 Self 要求无法作为一流的存在类型（例如，[MyProtocol]）工作，因为编译器缺乏构造与关联类型相关的见证表所需的具体类型元数据。这个限制阻止了异构集合直接存储实例，因为关联类型在符合类型之间的内存布局是不同的。开发人员通过类型擦除模式解决这一约束，实施利用协议见证表或基于闭包的调度的封箱包装器，以统一接口访问，同时封装底层的关联类型复杂性。
在架构一个跨平台媒体引擎时，我们的团队需要一个 PlaylistController，能够管理各种音频编解码器——包括 MP3、AAC 和 FLAC——每个编解码器都实现了具有表示解码音频样本的关联 Buffer 类型的 Playable 协议。不同格式的关联 Buffer 差别很大：FLAC 的未压缩 PCM 数据与 MP3 的压缩包，导致了不兼容的内存布局，阻止了标准的多态存储。
一种方法是通过 Playlist<T: Playable> 利用泛型特化，将整个集合约束为一种具体类型。这消除了运行时调度开销并允许激进的编译器优化，如内联。然而，这种方法完全牺牲了多态性，阻止用户在同一播放列表结构中混合 MP3 和 FLAC 曲目。
另一种选择是开发人员可以利用 Swift 的原生存在容器，通过现代 Swift 中可用的 [any Playable] 语法。虽然这支持异构存储，但访问关联的 Buffer 类型需要在每个调用点手动打开存在类型，这会创建冗长的样板代码并迫使大型值类型进行堆分配。此外，具体类型信息的丧失阻止了编译器去虚拟化方法调用，在紧密的音频处理循环中引入了可度量的开销。
最佳解决方案是实现一个名为 AnyPlayable 的手动类型擦除盒，利用基于闭包的见证表来委托 play() 和 stop() 方法。这个包装器将具体实例存储在基于类的容器或存在缓冲区中，隐藏了关联类型的复杂性，同时暴露出一个统一的接口。尽管这在开销上与虚拟调度相当，但它成功地抽象了缓冲区实现的差异，并支持真正的异构集合，而无须运行时类型转换的复杂性。
我们选择类型擦除包装器的方法，因为媒体应用程序在本质上要求在统一播放列表中混合各种编码，而虚拟调度的开销相较于音频流中的 I/O 延迟依然微不足道。该实现使专有 DRM 格式与标准编解码器的无缝集成成为可能，而无需修改 Controller 的架构。最终，这在曲目初始化期间维护了编译时的类型安全，同时提供了用户策划内容库所必需的运行时灵活性。
问题 1：为什么我们不能简单地用 as! any Playable 将具体类型转换为存在类型，当涉及到关联类型时？
Swift 禁止将带有关联类型的协议作为裸存在类型使用，因为存在容器需要固定大小的内联存储（通常是三个字），而关联类型可能需要任意大的内存占用。当 Buffer 关联类型对于 FLAC 表示一个 512 字节的解码帧，而对于 MP3 则是一个 4 字节的数据包索引时，存在类型就无法在不知道具体类型的情况下静态地容纳两个内存。结果，编译器强制执行类型擦除或泛型约束，以确保内存安全，防止因堆栈损坏或缓冲区溢出造成的运行时崩溃。
问题 2：Swift 5.1 的不透明返回类型 (some Collection) 与类型擦除盒在性能和 API 进化方面有什么不同？
不透明返回类型利用反向泛型和编译时特化，允许编译器保留完整的具体类型信息，同时隐藏调用者的实现细节。这避免了手动类型擦除盒所固有的虚拟调度惩罚和堆分配成本。然而，不透明类型要求在返回点的底层类型保持固定（不包括 SE-0368 多个不透明结果），而类型擦除盒允许在运行时同一容器内的具体类型动态变化，牺牲了性能以换取多态灵活性。
问题 3：当类型擦除盒在多线程环境中捕获自引用协议（例如，返回 Self 的方法的协议）时，会出现哪些内存管理风险？
类型擦除盒经常使用基于类的包装器或闭包捕获来存储具体实例。当协议要求返回 Self 或使用引用 Self 的关联类型时，盒子必须通过引用语义保留类型标识，这可能会造成如果具体类型持有对盒子的反向引用时潜在的保留循环。在并发上下文中，多个线程变更被盒住的状态可能会导致对引用计数或内部缓冲区的竞争条件。开发人员必须确保包装器恰当地遵循 Sendable，通常通过实现 Actor 隔离或盒子内不可变值语义，从而防止数据竞争，同时保持擦除的接口抽象。