企业官网建设流程全解析

1. 别把枚举当常量看，它是Swift里最被低估的类型

平时跟同行聊Swift，大家讨论最多的总是泛型、协议、Result、async/await这些“显眼包”。但说实话，我这些年写下来，真正在项目里帮我兜住大量边界问题、把代码组织得井井有条的，反而是看起来最不起眼的枚举。

在很多语言里，枚举只是个“整型常量表”，比如Java传统写法里的public static final int。但在Swift里，枚举是一种一等公民类型，它可以携带数据、定义方法、遵守协议、支持泛型，甚至能表达递归的数据结构。它不是用来“存几个固定值”的，而是用来“描述一组互斥状态”的。

这篇文章我会从最基础的枚举声明讲起，一路写到关联值、递归枚举、模式匹配、状态机设计，最后分享一些实际项目中的避坑经验和设计思路。无论你是刚接触Swift的新手，还是已经写了两年iOS但只用过简单枚举的老手，这篇文章都能帮你把枚举这块拼图彻底补上。

先说一个我自己的观察：很多Bug不是逻辑复杂度造成的，而是“状态没有被建模清楚”。比如一个网络请求，你用一个Bool表示isLoading，用另一个数组表示data，再用一个Error对象表示错误——这三个变量之间就可能出现“既在加载又有数据”的非法组合。如果换成枚举去建模，编译器会在你写出非法状态的那一刻直接报错。这就是枚举最大的价值：它把“非法状态”从运行时挪到了编译期。

2. 基础语法与关联值：把状态和数据绑在一起

2.1 声明与使用：case只是起点

Swift里声明一个枚举非常直接：

enum Direction { case north case south case east case west }

也可以写在一行：

enum Planet { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune }

使用起来：

let direction = Direction.north // 类型已知时可以省略枚举名 var currentDirection: Direction = .north

这里有一个关键点：枚举类型是被Swift的类型系统严格管理的。你不能把一个Direction赋给另一个枚举类型，也不能把一个Int直接塞进去。对比C语言和Java，Swift枚举的每个case都是独立的值，不是整数的别名。

但如果你以为枚举就只能这样用，那你只看到了冰山一角。Swift枚举的真正威力，是从**关联值（Associated Values）**开始的。

2.2 关联值：让每个case自带“随身行李”

关联值允许你把额外的数据附加到每一个case上。比如我们要描述一个“下载任务”的状态：

enum DownloadState { case idle case downloading(progress: Double) case paused(progress: Double) case completed(data: Data) case failed(error: Error) }

注意，这里的下载中状态带了当前进度，暂停状态也带了进度，完成状态带了数据，失败状态带了Error。每一种状态所携带的数据，和它的语义是严格匹配的。

这种设计解决了我在文章开头提到的那个问题：非法状态组合根本写不出来。比如你不可能写出“一个下载已完成但进度是0.3”的状态，因为completed这个case根本就没有progress这个参数。

使用关联值时，通过switch和模式匹配来提取数据：

func handleDownload(_ state: DownloadState) { switch state { case .idle: print("什么都没干") case .downloading(let progress): print("下载中：\(progress * 100)%") case .paused(let progress): print("暂停在 \(progress * 100)%") case .completed(let data): print("拿到了 \(data.count) 字节") case .failed(let error): print("出错了：\(error.localizedDescription)") } }

switch在这里是配套使用的。编译器的穷尽性检查会要求你把所有case都写全，少一个就编译不过。这件事看起来“麻烦”，但实际上是在用编译期约束换取运行期的安全——switch语句天然不会漏掉情况。

关于关联值的提取，有几点实践心得：

• let和var的简写：case .downloading(let progress)可以简写成case let .downloading(progress)。多个关联值时写成case let .downloading(progress, speed)。
• 配合where条件过滤：你可以在case后面跟上where，做更精细的匹配。

case .downloading(let progress) where progress > 0.5: print("已经过半了")

• if case语法：如果你只关心某个case，不必动用完整的switch，可以用if case：

if case .downloading(let progress) = state { print("当前进度 \(progress)") }

这种写法在特定场景下比switch更轻量。不过需要注意的是，if case每次匹配的是一个case，如果多个case都要判断，还是switch更整洁。

注意：关联值不是“属性”，它没有存储空间的概念。你不能直接通过state.progress去访问关联值，必须先经过模式匹配。很多从Java转过来的朋友在这一步会不适应，但只要多用几次，就会感受到模式匹配带来的表达力。

2.3 原始值：和String/Int打交道的快捷方式

关联值是“枚举case自带数据”，而**原始值（Raw Value）**是给每个case设置一个固定的、同类型的默认值。两者看起来像，但用途完全不同。

enum HTTPMethod: String { case get = "GET" case post = "POST" case put = "PUT" case delete = "DELETE" }

声明原始值类型后，Swift会帮你生成两个非常方便的能力：

• 通过rawValue拿到原始值：

let method = HTTPMethod.post print(method.rawValue) // "POST"

• 通过原始值反向生成枚举实例：

if let method = HTTPMethod(rawValue: "GET") { print(method) // .get }

这里注意：HTTPMethod(rawValue:)返回的是可选值（Optional），因为传入的字符串完全可能匹配不上任何case。这也是Swift安全性的体现——不要把枚举构造方法当成字典查询，它并不会给你一个兜底值。

原始值为String的时候，如果没有显式赋值，Swift会使用case名作为默认rawValue：

enum Direction: String { case north, south, east, west } // Direction.north.rawValue == "north"

这对“枚举类型转换为字符串”的需求非常实用。我之前做过一个接口对接的活，后端返回的订单状态是“PENDING / PAID / SHIPPED / COMPLETED”，前端需要一个状态枚举。直接把枚举的rawValue设计成和后端字符串一致，解析时一行代码搞定，还省去了一大堆if-else字符串判断。

何时用原始值，何时用关联值？我的经验是：如果case本身只需要一个固定值，比如网络方法名、后端的枚举状态字符串，那就用原始值；如果case需要携带动态数据，比如进度、数据、错误对象，那就用关联值。两者也可以混用，比如一个case既有一个固定的rawValue，又可以携带关联数据。

2.4 遍历所有case：CaseIterable的用法

调试、测试UI、生成随机选项的时候，经常需要把枚举的所有case遍历一遍。Swift提供了一个协议叫CaseIterable，声明后自动获得allCases：

enum ColorTheme: String, CaseIterable { case light, dark, system } for theme in ColorTheme.allCases { print(theme.rawValue) }

这个特性在设置页生成选项列表时特别有用。我之前做App的“外观设置”就是用它直接把三种主题渲染成一组单选按钮，以后新增主题只需要在枚举里加一个case，UI自动多出一个选项，不用再改任何配置逻辑。

注意：CaseIterable只对没有关联值的枚举自动生成allCases。一旦case携带了关联值，编译器就没法自动枚举出所有可能了——因为关联值理论上可以有无限多种取值。

3. 高阶玩法：递归枚举、协议与模式匹配

3.1 Indrect关键字：描述递归数据结构

有一类数据结构天然是递归的，比如链表、树、表达式。Swift用**递归枚举（Recursive Enumeration）**来处理这类场景。

举个例子，一个简单的算术表达式：

enum Expression { case number(Int) case add(Expression, Expression) case multiply(Expression, Expression) }

乍一看没啥问题，但Swift编译器会告诉你出错：“Recursive enum 'Expression' is not marked 'indirect'”。这是因为枚举在Swift里是值类型，值类型如果有递归引用，会导致无限的内存占用，编译器无从计算它的大小。

解决办法是在case前加上indirect关键字：

enum Expression { case number(Int) indirect case add(Expression, Expression) indirect case multiply(Expression, Expression) }

或者更省事，直接在整个枚举前加indirect，表示所有case都允许递归：

indirect enum Expression { case number(Int) case add(Expression, Expression) case multiply(Expression, Expression) }

有了这个定义，我们就可以构造表达式树了：

let expr = Expression.add(.number(1), .multiply(.number(2), .number(3)))

而计算表达式可以通过递归+模式匹配实现：

func evaluate(_ expr: Expression) -> Int { switch expr { case .number(let value): return value case .add(let left, let right): return evaluate(left) + evaluate(right) case .multiply(let left, let right): return evaluate(left) * evaluate(right) } } print(evaluate(expr)) // 7

这里要注意的是，indirect枚举不开箱即用地解决所有问题。它在底层本质上是把关联值放在了堆上，通过指针间接引用，所以你的数据结构可以任意嵌套而不受栈大小的限制。实际项目中，JSON解析树、命令解析器、配置表达式引擎都可以用它来建模。如果你接触过函数式编程语言里的代数数据类型，Swift的indirect枚举就是相似的概念。

3.2 让枚举遵守协议：从Codable到自定义行为

枚举作为一等类型，可以遵守任何协议。最常见的用途有两种：Codable（序列化）和自定义行为协议。

先看Codable：

enum ServerResponse: Codable { case success(data: Data) case failure(code: Int, message: String) }

Swift 5.5之后，编译器能自动为枚举合成Codable的实现，只要所有关联值类型都遵守Codable。这比手写decode和encode要省太多事了。但这里有一个关键细节：自动合成的JSON格式是带tag的，形式大概是：

{"success": {"data": [1,2,3]}}

如果你需要和后端对齐的是“扁平化”格式，比如：

{"status": "success", "data": [1,2,3]}

那就要手动实现init(from:)和encode(to:)。我的建议是：能用自动合成的场景第一优先，但如果你发现API的格式很特殊，别强求，手动实现也就几十行代码。

再看自定义协议。枚举很适合用来规范“一组操作”，比如给不同类型的推送通知定义一个协议：

protocol NotificationType { var title: String { get } var priority: Int { get } func handle() }

然后让不同的枚举case分别提供不同的实现：

enum AppNotification: NotificationType { case friendRequest(from: String) case newMessage(from: String, content: String) case systemAnnouncement(content: String) var title: String { switch self { case .friendRequest: return "好友请求" case .newMessage: return "新消息" case .systemAnnouncement: return "系统公告" } } var priority: Int { switch self { case .systemAnnouncement: return 10 case .friendRequest: return 5 case .newMessage: return 8 } } func handle() { switch self { case .friendRequest(let from): print("处理好友请求：\(from)") case .newMessage(let from, let content): print("处理消息：\(from) 发来 \(content)") case .systemAnnouncement(let content): print("处理公告：\(content)") } } }

注意：这里有一个设计上的取舍。枚举遵守协议后，switch还是会在每个方法里出现一次。如果case很多、方法也多，枚举文件的代码会比较长。但好处是：所有类型相关的逻辑都集中在一个文件里，可读性和维护性非常强。什么时候把switch集中放在枚举内部、什么时候使用协议扩展、什么时候用if case，这是Swift程序设计里值得长期打磨的地方。

比较推荐的一个原则：如果业务逻辑需要根据枚举case分流且分支稳定，直接写switch；如果未来可能有新的case加入，且不同case的差异非常大，那就优先考虑用协议或类来建模。枚举适合“有限且明确”的状态集合，不适合无边界增长的领域。

3.3 模式匹配：switch、if case、guard case的组合拳

模式匹配在处理枚举时极具表现力，我认为这是Swift枚举最有魅力的部分。

先说带值匹配：

enum Barcode { case upc(Int, Int, Int, Int) case qrCode(String) } let code = Barcode.qrCode("hello") switch code { case .upc(let a, let b, let c, let d): print("UPC：\(a)-\(b)-\(c)-\(d)") case .qrCode(let content): print("QR：\(content)") }

模式匹配还可以用下划线忽略某个关联值：

switch code { case .upc(let a, _, _, _): print("第一段是\(a)") case .qrCode: break }

然后是组合匹配，多个case合并为一个分支：

switch direction { case .north, .south: print("垂直方向") case .east, .west: print("水平方向") }

再用where加上条件：

switch progress { case let .downloading(p) where p < 0.3: print("刚开始") case let .downloading(p) where p < 0.7: print("进行中") case let .downloading(p): print("快完了") default: break }

如果要嵌套使用，比如一个枚举里嵌套另一个枚举：

switch state { case .success(let data) where data.isEmpty: print("成功但数据为空") case .failure(.networkError): print("网络错误") case .failure(let error) where error == .timeout: print("超时") default: break }

这里提醒新手一点：switch的case分支是自上而下匹配的，一旦命中一个分支就不会继续往下。所以在使用where条件时，注意把更具体的条件写在前面，把通用兜底写在后面，否则永远匹配不到后面的分支。

除了switch，guard case也能做模式匹配，常用于“只有满足某条件才继续执行”的校验场景：

guard case .downloading(let progress) = state, progress > 0 else { return } print("下载有效进度：\(progress)")

3.4 枚举里的计算属性和方法

枚举可以定义计算属性、实例方法和静态方法，这是被很多Swift新手忽视的能力。

enum NetworkState { case connecting case connected case disconnected var description: String { switch self { case .connecting: return "连接中" case .connected: return "已连接" case .disconnected: return "未连接" } } func canRetry() -> Bool { switch self { case .disconnected: return true case .connecting, .connected: return false } } static func random() -> NetworkState { return [.connecting, .connected, .disconnected].randomElement()! } }

使用场景很灵活：一个订单状态枚举可以提供一个计算属性来获取对应的颜色、图标、展示文案；一个交通灯枚举可以提供一个方法判断“下一秒该变什么灯”。这些逻辑放在枚举内部，比散落在各自View里要有序得多。

注意：枚举是值类型，所以它的方法默认不能修改自身。如果要实现类似“状态流转”的修改行为，需要使用mutating关键词：

enum ProgressState { case notStarted case inProgress(percent: Double) case done mutating func advance() { switch self { case .notStarted: self = .inProgress(percent: 0.0) case .inProgress(let percent): if percent >= 1.0 { self = .done } else { self = .inProgress(percent: percent + 0.1) } case .done: break } } }

这其实就是一个小型状态机的雏形，下面会专门展开讲。

4. 实战场景：状态机、错误处理与配置管理

4.1 用枚举搭一个完整的状态机

状态机在客户端开发里太常见了：下载、上传、登录、播放器、页面加载……几乎每个需求都隐含一个状态流转过程。用枚举建模状态机，是我个人认为Swift枚举最值得投入实践的场景。

以音视频播放器为例：

enum PlayerState { case idle case buffering(progress: Double) case playing(currentTime: TimeInterval) case paused(currentTime: TimeInterval) case ended case failed(error: Error) var isPlaying: Bool { if case .playing = self { return true } return false } var isActive: Bool { switch self { case .idle, .ended, .failed: return false case .buffering, .playing, .paused: return true } } }

然后定义事件驱动的状态迁移方法：

extension PlayerState { mutating func handle(event: PlayerEvent) { switch (self, event) { case (.idle, .load): self = .buffering(progress: 0) case (.buffering, .bufferProgress(let p)): self = .buffering(progress: p) case (.buffering, .readyToPlay): self = .playing(currentTime: 0) case (.playing, .pause): self = .paused(currentTime: currentTimeFromSelf()) case (.paused, .resume): self = .playing(currentTime: currentTimeFromSelf()) case (.playing, .playToEnd): self = .ended case (_, .error(let error)): self = .failed(error: error) default: // 非法状态迁移，记录日志或忽略 break } } }

这里使用switch (self, event)进行二元匹配，能非常直观地列出“当前状态+触发事件 → 下个状态”的所有组合。编译器会帮你穷尽所有组合，漏掉某个情况时会警告你未处理。

实际项目中，这套方案有几个非常明显的收益：

• 所有允许的状态流转全部摊在明面上，新同事拿到代码不需要问别人“这个状态能不能直接跳过去”。
• 非法迁移在编译期就被约束，不需要写大量的if-else防御。
• 排查问题时只需要看状态值，不需要看一堆Bool变量互相组合。

注意：状态机切分粒度很关键。一是把“状态”（state）和“事件”（event）分开建模，不要混淆。二是尽量避免一个大枚举承载太多维度，例如同时表达“加载中/有数据/有错误”三个维度时，可以先做一个“加载状态”枚举，再做一个“内容可用性”枚举，再组合成一个struct，而不是塞进一个巨大的枚举里让case数量爆炸。

4.2 错误处理的正确姿势：Error协议与枚举的黄金搭档

Swift的错误处理机制里，协议Error和枚举是天然搭配。我一直认为，自定义错误类型的第一选择应当是枚举，因为业务错误的种类通常有限且可穷举。

enum NetworkError: Error { case badURL case timeout case serverError(code: Int, message: String) case noData case unauthorized }

用起来：

func fetchUser(completion: (Result<User, NetworkError>) -> Void) { // ... }

Result枚举本身也是Swift标准库里的一个枚举，定义是：

public enum Result<Success, Failure: Error> { case success(Success) case failure(Failure) }

这里要特别表扬一下Result的设计：它把“成功携带数据”和“失败携带错误”都压进了同一个小枚举里，配合switch处理，可以避免回调里出现“data为空但error也为空”的尴尬情况。

错误枚举设计的三条经验：

1. 不要用NetworkError.popularError这种笼统case。错误种类越具体，调用方越容易针对性地处理；笼统的case等于把错误信息又藏回了字符串里。
2. 保留关联值里的上下文。比如服务端错误码、用户可读文案，应作为关联值，而不是让调用方自己去解析一个Int或String。
3. 涉及UI提示时，在枚举上扩展一个显示用属性，不要把错误转字符串的逻辑散落在各个ViewController里。

extension NetworkError { var userMessage: String { switch self { case .badURL: return "地址无效" case .timeout: return "连接超时，请重试" case .serverError(let code, let message): return "服务异常（\(code)）：\(message)" case .noData: return "暂无数据" case .unauthorized: return "登录已过期，请重新登录" } } }

这样，UI层调用error.userMessage即可展示，逻辑层也可以直接用枚举比较错误类型来做精细化分流。

4.3 配置与策略模式的枚举化改造

最后一个高频实战场景是用枚举管理配置项和策略。

App内部往往有大量“根据类型不同而行为不同”的逻辑。比如订单状态对应不同的界面展示、推送消息根据类型走不同跳转、支付渠道有各自的手续费和有效期。这类逻辑可以用枚举加switch很好地组织。

我们来看一个订单状态的例子：

enum OrderStatus: String, Codable { case pendingPayment = "PENDING_PAYMENT" case paid = "PAID" case shipped = "SHIPPED" case completed = "COMPLETED" case cancelled = "CANCELLED" var badgeText: String { switch self { case .pendingPayment: return "待付款" case .paid: return "已付款" case .shipped: return "已发货" case .completed: return "已完成" case .cancelled: return "已取消" } } var badgeColor: String { switch self { case .pendingPayment: return "#FF9800" case .paid: return "#2196F3" case .shipped: return "#4CAF50" case .completed: return "#9E9E9E" case .cancelled: return "#F44336" } } var allowsCancel: Bool { switch self { case .pendingPayment, .paid: return true case .shipped, .completed, .cancelled: return false } } }

后端返回的字符串直接可以被解析成枚举，页面展示时也不需要再做任何字符串判断，全部行为都从枚举身上拿。

另一种策略场景是支付渠道。假设App支持支付宝、微信、银联三种渠道，可以定义策略接口：

protocol PaymentChannel { func pay(amount: Decimal, completion: @escaping (Bool) -> Void) var feeRate: Decimal { get } } enum PaymentType: String, CaseIterable, PaymentChannel { case alipay = "ALIPAY" case wechat = "WECHAT" case unionPay = "UNIONPAY" var feeRate: Decimal { switch self { case .alipay: return 0.006 case .wechat: return 0.006 case .unionPay: return 0.002 } } func pay(amount: Decimal, completion: @escaping (Bool) -> Void) { // 根据各自渠道调起支付SDK } }

一线的iOS开发者都知道，Swift枚举的功能远不止“定义一组常量”这么简单。只要不断挖掘它的特性，就能真正建立起Swift的思维方式：用类型系统把约束前置，让编译器成为你的第一道防线。

5. 经验与踩坑：为什么我建议你在项目里多用枚举

5.1 常见误区：用过==、RawValue和Codable时的隐患

先说一个几乎每个人都踩过的坑：直接用枚举去比较关联值。普通枚举可以这样比较：

if direction == .north { print("向北") }

但带关联值的枚举不能直接用==比较，因为它没有自动合成Equatable。Swift里，Equatable协议需要在编译时明确知道你所说的“相等”指什么。两种做法：

• 手动实现Equatable：

extension DownloadState: Equatable { static func == (lhs: Self, rhs: Self) -> Bool { switch (lhs, rhs) { case (.idle, .idle): return true case (.downloading(let lp), .downloading(let rp)): return lp == rp case (.paused(let lp), .paused(let rp)): return lp == rp case (.completed(let ld), .completed(let rd)): return ld == rd case (.failed(let le), .failed(let re)): return le.localizedDescription == re.localizedDescription default: return false } } }

• 如果你的需求只是判断“是否为某个case”，用if case更轻量：

if case .downloading = state { print("在下载中") }

第二个常见误区是滥用原始值，却不用关联值。我见过不少代码写一个巨大的枚举，每个case对应一个字符串，然后到处对比rawValue。这种写法的本质还是C语言枚举的思维，Flat比较松散。正确的做法是：如果这个case需要“动态附带数据”，第一时间应该考虑关联值，而不是把数据编码成一个字符串再塞进rawValue。

第三个误区是关于Codable的。Swift自动合成的枚举Codable在有默认值的case、旧的字段移除、兼容历史版本等场景下容易出问题。比如你本来有case gold，后来产品移除了这个等级，但旧版本客户端还在保存这个值。自动合成的解码遇到未知case会直接抛错。这时候就需要手动处理容错逻辑，比如增加一个case unknown，并在init(from:)里用decodeIfPresent或者字符串比对来处理未识别值。

5.2 性能：枚举是值类型，但别担心

关于枚举的性能，有两个问题经常被问到。

第一个是“枚举的关联值存在哪里”。普通的无关联值枚举在内存中通常只占1个字节，用于存放case索引（编译器会有最小字节数优化）。带关联值的枚举内存大小是“最大的那个关联值的大小 + 一个discriminant（区分case的标记）”，并会按对齐规则取整。如果你把一个Data关联进去，那这个枚举的内存占用会明显变大，因为Data本身是个堆分配的结构体。

不过现代Swift编译器对枚举的优化是相当激进的，它甚至会在条件允许时把整型索引和关联值压缩进同一个寄存器，让枚举的访问速度几乎不比普通struct慢。所以我的结论是：该用枚举就用，不要因为担心性能而改用包含多个可选属性的struct。后者不仅内存更大，还更容易出现非法状态组合。

第二个是关于递归枚举（indirect）的性能。因为递归关联值存储在堆上，访问会经过一次间接跳转，相比栈上的普通枚举会多一点点开销。但表达式树、链表这类数据结构的节点数量通常有限，这点开销微乎其微。真正需要警惕的反而是你在这个枚举里塞进了一个超大容量的数组或字典，导致每次值拷贝时发生一次完整的深拷贝——不过在COW（写时复制）机制下，只有mutating时才真正复制，使用场景大多是读取时，性能完全可控。

5.3 我的几种枚举设计模式

最后分享几种我实际项目里反复使用的设计模式。

模式一：包装可选状态。用枚举替代“可选属性+Bool”的组合，避免状态冲突：

enum LoadState { case loading case loaded(contents: [Item]) case empty case error(message: String) }

页面只需要维护这一个枚举，根据它的case自动刷新UI。不要再用isLoading、hasData、errorMessage三个变量分开管理——那种做法看似灵活，实际上让页面状态进入了“三体问题”式的混沌。

模式二：导航路由。用枚举描述App内页面跳转：

enum Route { case profile(userID: String) case settings case orderDetail(orderID: String) case webPage(url: URL) }

配合一个Router函数统一处理跳转，传参和类型检查全部由编译器把关，比“字符串URL+路由表”方案安全得多。

模式三：相关状态聚合。当多个枚举需要组合时，把它们合起来：

enum ConnectionState { case disconnected case connecting case connected(ConnectionInfo) } enum ConnectionAction { case connect case disconnect case reconnect }

用switch (connectionState, action)来编排状态流转，一目了然。上面播放器状态机的写法就是这种模式的延伸。

5.4 从“会用”到“用好”的进阶建议

如果想再往上走一步，我建议多思考几个方向。

第一是泛型枚举。枚举支持泛型参数，比如Result<Success, Failure>就是泛型枚举的典型代表。随后你会发现“可选错误处理”“懒加载”“异步结果”都可以通过泛型枚举来表达。

第二是与SwiftUI的配合。SwiftUI中的@Observable、状态驱动UI的设计，和枚举建模状态机的理念高度契合。在ViewModel里维护一个枚举状态，View根据它来渲染，代码比分散的可选绑定点要干净得多。

第三是自定义模式下匹配的实现。实际上协议的associatedtype也有类枚举的一面。如果你发现枚举case多到开始承载复杂行为，请立即停下来评估：是不是该把某些case替换成具体的类型（类或结构体）了？枚举的适用边界是“状态有限且互斥”，一旦类型开始膨胀，它就不再是最优选择了。

我个人在实际项目里的体会是：枚举不是一种语法糖，而是一种设计思维。它逼着你在写代码之前把问题域理清楚，把一个事物的所有可能状态都摆在明面上。这种思维带来的长期收益，远比某个case提供的那点便利更宝贵。写Swift不学会用好枚举，等于拿着一台相机却只用自动模式，永远拍不出真正有表达力的照片。