Swift中Enum枚举case数量过多是否有问题？适配替代方案有哪些？

问题1：包含1000个以上case的Enum能否正常运行？是否存在潜在问题？适合的替代数据结构是什么？ #

Swift语法本身没有限制枚举的case数量，1000个以上case的枚举可以正常编译运行，但存在非常多的实际问题：

• 编译效率大幅下降，枚举的元数据生成、CaseIterable协议的自动实现、穷尽性检查都会额外消耗大量编译资源，增量编译时修改相关文件的等待时间会明显变长
• 安装包体积增大，千条case对应的枚举元数据、跳转表等内容会占用额外的二进制存储空间
• 维护成本极高，每次新增/删除case都需要同步修改所有关联的switch分支，漏改就会触发编译错误，人工维护千条条目很容易出现失误

这个场景下最合适的替代方案是用结构体封装，而非硬编码枚举case，示例实现如下：

// 基础结构体实现，对应原枚举的功能
struct Name: Hashable, CaseIterable {
    static var allCases: [Name] = (1...1000).map { Name(id: $0) }
    
    let id: Int
    
    var string: String {
        // 如果字符串是固定规则拼接，直接生成即可
        "Name \(id)"
    }
}

// 如果存在少数不符合规则的自定义字符串，用字典单独存储映射即可
private let customStringMap: [Int: String] = [
    12: "自定义名称A",
    37: "自定义名称B"
]

extension Name {
    var customString: String {
        customStringMap[id] ?? "Name \(id)"
    }
}

如果不需要枚举的类型安全约束，也可以直接用[Int: String]字典存储映射关系，实现更轻量。

问题2：计算属性中包含1000个以上case的Switch语句是否会引发问题？ #

语法层面这类Switch语句可以正常运行，但实际使用中问题明显：

• 编译阶段的穷尽性检查耗时会显著增加，每加一个case就要重新遍历所有分支做校验
• 维护成本极高，枚举每次更新case都要同步修改Switch的分支，千条级别的条目手动同步容错率极低
• 运行效率并没有明显优势，千条case的Switch虽然会编译为O(1)的跳转表，但和字典查找的性能差异极小，完全不足以抵消维护层面的劣势

内容的提问来源于stack exchange，提问作者christophriepe