🦍 引子
旧金山废墟的猿族技术区，金属支架撑起的荧光屏泛着冷光，首席 Swift 架构师科巴的指节因攥紧终端而发白 —— 食物计数系统又出问题了。
刚录入的 27 根香蕉，刷新页面竟变成 29，再点一下又跳回 28，旁边年轻猿工程师紧张地挠着头：“科巴大人，不会是小猩猩偷偷改数据吧？” 科巴瞪了他一眼：“是‘并发幽灵’！自从用 Actor 保护状态，简单的计数全成了麻烦 —— 查个库存要写await，就像咱们去仓库拿根香蕉，得先找凯撒签字、找后勤登记，折腾半小时！”
在本堂猩猩课堂中，您将学到如下内容：
- 🦍 引子
- 🛡️ 第一章：Actor 的麻烦 —— 被异步绑架的简单需求
- 🔧 第二章：Mutex 实战 —— 零 bug 香蕉计数器
- 📱 第三章：适配 SwiftUI—— 让 @Observable “看见” 变化
- ⚔️ 第四章：抉择 ——Mutex vs Actor
- 🌟 结尾：代码丛林的生存法则
今天，他要拿出压箱底的 “轻量武器” Mutex，让代码既能挡住并发风险，又能像猿族奔袭般迅猛如潮。
🛡️ 第一章：Actor 的麻烦 —— 被异步绑架的简单需求
科巴拉过一把生锈的金属椅坐下，指尖在键盘上敲出 Actor 代码：“你们看，要改香蕉数量，必须写await counter.addBanana()—— 就一个破赋值操作，硬生生被拖进异步队列！”
他顿了顿，指着屏幕上的@MainActor标签，“就算把计数器绑在主线程，其他哨站的猿想查库存，还是得等主线程‘有空’—— 这和把仓库钥匙只给主营地的猿，其他猿只能站在门口等，有啥区别？”
旁边的猿工程师小声问：“那以前咱们是怎么处理的？”
“以前靠 GCD 串行队列！” 科巴一拍桌子，“就像给仓库配个专属管理员，所有拿香蕉的请求都排队，谁也别插队。但队列太重了，现在 Swift 出了 Mutex—— 它是‘轻量级锁’，只护一小块状态，操作完自动解锁，还不用写一堆异步代码！”
🔧 第二章：Mutex 实战 —— 零 bug 香蕉计数器
科巴清了清嗓子，手指在键盘上飞快跳动，边写边讲解：“Mutex 的核心是withLock方法 —— 它会先‘抢锁’，确保当前只有一个线程能操作状态，操作完不管成功或失败，都会自动‘释放锁’，绝不会像手动加锁那样，忘了解锁导致整个系统卡死。”
很快，FoodCounter类的代码出现在屏幕上：
1class FoodCounter { 2 // 初始化 Mutex，把初始香蕉数设为0——相当于给空仓库装了把新锁 3 private let mutex = Mutex(0) 4 5 // 增加香蕉：开锁、给库存+1、自动锁门 6 func addBanana() { 7 mutex.withLock { count in 8 count += 1 // 操作超简单，就像把香蕉放进仓库，一秒搞定 9 } 10 } 11 12 // 减少香蕉：逻辑和加香蕉一样，只是把+1改成-1 13 func removeBanana() { 14 mutex.withLock { count in 15 count -= 1 16 } 17 } 18 19 // 读取库存：重点！读操作也要走 withLock，防止读的时候正好在写（比如刚加了半根香蕉） 20 var bananaCount: Int { 21 mutex.withLock { count in 22 return count // 只读取，不修改，但也要保证独占访问 23 } 24 } 25} 26
“千万别犯懒！” 科巴突然提高声音，“有猿觉得‘读操作不用锁’，结果读的时候正好赶上写，拿到的是‘脏数据’—— 上次有个猿没加锁读库存，以为还有 10 根香蕉，结果实际只剩 2 根，导致整个哨站的猿饿了半天！”
他演示了如何使用计数器，代码简洁得让猿工程师们发出惊叹：
1let counter = FoodCounter() 2 3counter.bananaCount = 10 // 直接赋值，不用等异步 4print(counter.bananaCount) // 立刻输出10，没有半点延迟 5counter.addBanana() 6 7print(counter.bananaCount) // 输出11，实时更新 8
📱 第三章：适配 SwiftUI—— 让 @Observable “看见” 变化
正当猿族为新计数器欢呼时，负责 SwiftUI 仪表盘的猿跑过来：“科巴大人，计数器接入界面后，香蕉数变了，界面却一动不动！” 科巴凑过去看了眼平板 —— 屏幕上的数字始终停留在 10，哪怕点了 “加香蕉” 按钮也没反应。
“这是因为 @Observable ‘瞎’了！” 科巴很快找到问题，“Mutex 保护的是内部的库存数，库存变了，但 Mutex 本身没变化 ——@Observable 只能‘看见’对象属性的直接修改，看不到 Mutex 里面的小动作。”
他伸手在键盘上敲了几行代码，给bananaCount的get和set加了 “传令兵”：
1@Observable 2final class FoodCounter: Sendable { // 加Sendable，允许计数器跨线程传递 3 private let mutex = Mutex(0) 4 5 var bananaCount: Int { 6 get { 7 // 告诉@Observable：“有人在读香蕉数量啦，记下来！” 8 self.access(keyPath: \.bananaCount) 9 return mutex.withLock { $0 } 10 } 11 set { 12 // 告诉@Observable：“香蕉数量要变了，准备更新界面！” 13 self.withMutation(keyPath: \.bananaCount) { 14 mutex.withLock { count in 15 count = newValue 16 } 17 } 18 } 19 } 20 21 // 省略addBanana和removeBanana... 22} 23
“这俩方法是 @Observable 宏自动加的‘钩子’，” 科巴解释，“access告诉框架‘有人在读数据’，withMutation告诉框架‘数据要改了’—— 这样界面就能跟 Mutex 里的库存同步，点一下按钮，数字立刻更新，童叟无欺！”
⚔️ 第四章：抉择 ——Mutex vs Actor
科巴把猿族工程师召集到一起，在黑板上画了张对比表，用炭笔重重标出关键差异：
| 对比维度 | Mutex（轻量锁） | Actor（异步卫士） |
|---|---|---|
| 代码风格 | 同步代码，不用写await，清爽直接 | 强制异步，处处要await，略显繁琐 |
| 适用场景 | 保护 1-2 个简单属性（如计数）、操作耗时极短 | 保护复杂对象（如网络管理器）、操作耗时较长（如下载图片） |
| 线程行为 | 抢不到锁会 “阻塞”（等锁释放） | 抢不到隔离权会 “挂起”（不阻塞线程） |
| 学习成本 | 低，API 简单，上手快 | 高，要理解隔离域、Sendable 等概念 |
“选哪个不是看‘谁更强’，而是看‘谁更适合’！” 科巴敲了敲黑板，“如果你的需求像‘数香蕉’一样简单，不想写一堆异步代码，就用 Mutex—— 它是‘贴身短刀’，快准狠；如果你的需求是‘跟人类服务器同步数据’，要处理一堆异步逻辑，就用 Actor—— 它是‘坚固盾牌’，能扛住复杂并发。”
他顿了顿，补充道：“我通常会两种都试一下，哪个写起来顺手就用哪个。比如这次的计数器，用 Mutex 写出来的代码比 Actor 简洁一半，还不用处理异步等待，那肯定选 Mutex 啊！”
🌟 结尾：代码丛林的生存法则
科巴把最后一行代码提交到猿族的代码仓库，终端屏幕上的香蕉计数稳定跳动 —— 从 100 跳到 101，又跳到 102，那是远方哨站的猿刚入库的香蕉，正通过 Mutex 守护的代码，实时同步到主营地的仪表盘。
他走到窗边，看着外面：凯撒正带领年轻的猿族围着平板学习 Swift，阳光透过废墟的缝隙洒在他们身上，像给代码世界镀上了一层金光。
科巴拉过身边的年轻猿工程师，指着屏幕上的 Mutex 代码说：“咱们猿族在丛林里生存，不会拿长矛去抓兔子，也不会拿匕首去对付狮子 —— 代码世界也一样，没有‘最强的工具’，只有‘最适合当下的工具’。Mutex 是短刀，适合近距离快速解决问题；Actor 是盾牌，适合抵御大规模的并发攻击。懂取舍，会选工具，才是真 - 正的工程师。”
平板上的计数又跳了一下，这次是 103—— 猿族的食物储备越来越多，他们的 Swift 代码，也在 Mutex 和 Actor 的守护下，越来越稳固。
那么，各位微秃小猩猩，你们学“废”了吗？感谢观看，下次再会啦！8-)
