引入 Swift 5.0 时，支持库演进的 @frozen 属性的设计旨在解决 API 可扩展性和二进制稳定性之间的紧张关系。在这一机制之前，弹性库中的所有公共枚举隐式为非冻结状态，迫使编译器假设未来版本可能会添加未知的情况。这一假设阻止了紧凑、固定大小布局的生成，并在客户端代码中强制执行防御性编程模式。此属性提供了正式的保证，确保枚举的案例清单在永远不变，这使得积极的优化成为可能。
问题出现在库发布没有这个属性的枚举时。Swift 必须将该枚举视为弹性，保留内存表示中的变量空间，以容纳未来的案例区分符和相关值布局。这迫使客户端的 switch 包含 @unknown default 情况，从而有效地禁用了编译时验证以确保所有逻辑状态都得到处理。没有这样的默认情况，将一个案例添加到库中会导致已编译的客户端二进制文件在缺乏处理新区分符值代码的情况下出现未定义行为，导致崩溃或内存损坏。
解决方案在于 @frozen 注释建立的永久合同。通过将枚举标记为被冻结，库作者承诺这个案例集合将永远不变，使得编译器能够分配固定整数标签，并使用稳定、紧凑的内存布局。这允许穷尽的 switch 语句没有默认情况，因为编译器可以证明区分符的所有可能位模式都对应着已知案例。由此产生的 ABI 稳定性确保了枚举的大小和对齐在库版本间保持不变，同时客户端代码受益于跳转表优化和对每个状态的强制处理。
// 在使用 -enable-library-evolution 编译的库中 @frozen public enum LoadState { case idle case loading case loaded(Data) } // 另一个模块中的客户端代码 func updateUI(for state: LoadState) { switch state { case .idle: print("等待") case .loading: print("加载中") case .loaded: print("内容") // 编译器验证穷尽性；不需要默认 } }
一家物流公司的平台团队正在发布一个用于路线优化的 Swift 包，该包公开了一个 TransportMode 枚举，其中包含 .truck、.air 和 .ship 的案例。由于他们预期在后续版本中添加 .drone 和 .rail，他们最初分发的库没有使用 @frozen 属性。客户端团队很快报告说，Xcode 拒绝在没有 @unknown default 子句的情况下编译 switch，这隐藏了他们在货运费用计算中忘记处理 .ship 的逻辑错误。
该团队考虑了三种架构方法来解决此问题。
首先，他们可以保持非冻结状态，并投资于重度 linting，以确保客户端编写 @unknown default 处理程序并记录警告。这保留了在不进行重大版本更改的情况下添加运输模式的灵活性，但永久禁用了编译时穷尽性检查。由于每个枚举实例都携带弹性元数据，这也未能解决二进制大小的开销，从而使发往驾驶员设备的序列化路线数据包膨胀。
其次，他们可以使用一个以整数常量为基础的 RawRepresentable 结构替换枚举。这将提供固定的内存布局，并允许添加新模式而不破坏二进制兼容性，但它将完全牺牲 Swift 的模式匹配能力。开发人员将被迫编写冗长的 if-else 链，并且编译器将无法再验证在关键路径查找算法中处理了所有可能的运输状态。
第三，他们可以将 @frozen 应用于枚举，并承诺现有的三个案例，为未来扩展创建一个单独的 ExtendedTransportMode 包装器。这将消除弹性开销，启用穷尽的 switch 编译，并确保每个客户端明确处理所有当前模式。权衡在于对修改原始枚举的永久限制，以及任何基础添加的版本控制需求。
他们选择了第三种解决方案。在冻结 TransportMode 后，他们立即在自己的分析仪表板中发现了两个未处理的 switch 情况。移除弹性元数据将传输的路线对象大小减少了 18%，而明确的架构边界迫使核心运输逻辑与实验模式之间的清晰分离。
为什么将案例添加到非冻结的公共枚举中会破坏二进制兼容性，即使客户端源代码仍然成功编译？
当 Swift 编译一个弹性模块时，非冻结枚举利用可变宽度表示，保留空间以容纳未来的案例区分符。如果库随后添加了一个案例，则枚举的运行时布局会发生变化——例如，区分符整数可能会从 8 位扩展到 16 位，以容纳新的标签。已编译的客户端二进制文件期望旧的布局，并且包含只针对原始标签范围的跳转表或条件分支。当这些二进制文件遇到新的区分符值时，它们可能会执行无效的代码路径或读取超出预期有效负载边界的内存，导致崩溃，而源级的 @unknown default 子句无法防止。
@frozen 如何与包含间接案例或弹性类型的关联值的枚举交互？
@frozen 保证案例的身份和数量保持不变，但它并不冻结关联值的大小。如果一个案例携带一个非冻结结构的有效负载或类引用，则枚举的 ABI 稳定性指的是固定的区分符标签，而有效负载存储可能仍然通过指针或值见证表利用动态大小。候选人常常错误地假设 @frozen 固定整个内存占用，包括有效负载大小；实际上，这种优化主要适用于标签，且关联值如果其类型本身是弹性的或包含未知大小，仍可能需要运行时布局计算。
可以在非弹性模块中声明冻结枚举吗？这样做的长期影响是什么？
是的，@frozen 可以应用于在常规应用程序目标中的枚举，其中库演进被禁用。在这个上下文中，该属性作为意图的文档，因为由于缺乏弹性边界，模块内的所有枚举实际上都是冻结的。然而，候选人常常忽视 @frozen 代表一个永久的 ABI 合同；如果该模块后来被提取到弹性库框架中，则不能解冻或扩展枚举，否则会破坏与现有客户端的二进制兼容性。在初始开发过程中明确标记枚举为冻结，可以为代码库提供保护，防止在项目架构演变时意外违反 ABI。