先说结论：Cursor 的某些操作例如自动更新过程在高内存压力场景下触发了极端 I/O 风暴，并高度疑似诱发 Apple Silicon watchdog reset。直接导致 Apple Silicon Watchdog 硬件强制复位------屏幕一黑，秒重启，什么提示都没有，只在 DiagnosticReports 里留下一个 ResetCounter。
疑似Cursor 的 updater workload 触发了 Apple Silicon 某个 VM/APFS/IOKit 路径里的 starvation bug。
一晚上三次，19:15、20:35、22:07，每次都是同一个原因。我是用系统诊断报告一步步追到的根因，证据全在下面。
现象
- 电脑正常使用中，突然黑屏
- 没有任何 beach ball、没有卡顿、也没有"你的电脑因为出现问题而重新启动"的提示
- 就是一瞬间黑掉，然后 Apple logo 亮起，重启完成
- 打开的所有东西没了，"重新打开窗口"救不回来
- Console.app 里这个时间段的日志是空的------统一日志缓冲区在硬件复位时直接蒸发
追凶
DiagnosticReports 目录里躺着三条 ResetCounter：
Date: 2026-05-17 20:36:39
Reset count: 1
Boot faults: wdog, reset_in_1 timeout, dblclick_timeout
wdog = Apple Silicon 的硬件看门狗。reset_in_1 timeout = 内核超过 1 秒没响应看门狗，硬件直接拉闸。这不是软件崩溃，是系统已经无响应到连 panic 流程都走不动了，纯靠硬件保底。
同目录下还有几条 disk writes 诊断------macOS 对单日写入超过 2.15 GB 的进程会自动采样微栈：
19:04-19:15 — ditto
Command: ditto PID: 55081
Event: disk writes 写入: 2.15 GB / 11 分钟
Stack: BOMCopierCopyWithOptions → _BOMCopierCopyFromPKZip
→ _copyDir → _copyFromPKZip → _copyDir → …（35层递归）
Resource Coalition: 12598（自身）, 137 samples 1439
ditto 在解压一个 zip，目录嵌套深到递归了 35 层才触到实际文件。问题是------谁调用了 ditto？
20:36-20:39 — Cursor
Command: Cursor PID: 979
Event: disk writes 写入: 2.15 GB / 150 秒（14.3 MB/s）
Stack: 177 个线程全部卡在 uv__fs_post → write()
1 个线程在 Squirrel → removeItem → __removefile_tree_walker → __unlink
Resource Coalition: 751, 34 samples 1439
177 个 libuv 线程池线程，全部在内核 write() 里。同时 Squirrel 在递归删除一个目录。注意 Cursor 和 ditto 都出现了 Coalition 1439。
对 Coalition 1439 做反向索引------在全量磁盘写入报告里搜所有带有这个 Coalition 的进程------结果只有一组：com.todesktop.230313mzl4w4u92（Cursor）及其子进程。
ditto 是 Cursor 启动的。
再查 Squirrel 的状态文件：
ShipItState.plist:
targetBundleURL: "/Applications/Cursor.app/"
updateBundleURL: "…ShipIt/update.z1tErYz/Cursor.app/" ← 从未完成安装
ShipIt 日志：
5月16日 19:24 Detected this as an install request
5月16日 23:01 Detected this as an install request ← 又来了
然后 Cursor 主日志，第三次死机前两分钟：
5月17日 22:04:36 update#setState checking for updates
5月17日 22:04:37 UpdateService onUpdateAvailable()
5月17日 22:04:37 update#setState downloading
5月17日 22:07------ResetCounter。
从 5月16日晚到 5月17日晚，Squirrel 一直在尝试安装同一个更新，每次都触发 I/O 风暴->死机->重启->Cursor 自启->Squirrel 发现更新没装完->再来一次。
为什么能打穿整台机器
三个 I/O 密集型操作同时发生：
操作 并发 I/O 类型 ditto 递归解压 35+ 层目录树创建 APFS inode 分配 + 目录写入 Cursor libuv 线程池 177 线程同时 write() 数据块写入 Squirrel 递归删除 旧版本目录树删除 APFS inode 回收 + 目录更新APFS 的元数据操作是串行化的。一边疯狂建目录，一边疯狂删目录，一边 177 个线程抢文件写入------元数据锁争抢到内核 I/O 工作队列被填满，关键的 watchdog 喂狗线程分不到 CPU。
我的日常负载（Chrome 十几个标签 + VS Code 多窗口 + OrbStack + postgres + mongod）当时内存压力已经把页面缓存挤出不少，这意味着文件写入还要跟 swap 抢 I/O 带宽。
结果就是内核整体无响应 >1 秒 → 硬件 watchdog 超时 → 黑屏重启。
Cursor 团队在这里省了什么
说三件事：
-
全量 zip 替换。 2026 年了，VS Code 都能做增量热更新，Cursor 的 Squirrel 框架还在下载全量包->解压->替换整个 app bundle。2.15 GB 的更新包，不是 delta patch，是整个 app 重新灌一遍。
-
零 I/O 限流。 ditto 解压没有 QoS（诊断报告显示 QoS 是 User Interactive，最高优先级）。libuv 线程池没有限制并发写入数。Squirrel 的
removeItem是递归__unlink，没有 batch，没有 throttle。 -
没有崩溃恢复。 更新安装失败后 Squirrel 的状态文件原样保留，下次启动直接重试，没有任何指数退避、没有失败次数上限、没有对"这台机器已经因为这个更新死过两次"的感知。硬着头皮再来一次，然后理所当然地再死一次。
Cursor Pro 订阅费不便宜。用户付了钱，换来的更新体验是机器被搞到硬件强制复位------这不是 bug，这是连最基本的系统资源管理都没做。
解决
如果你在用 Cursor，检查一下你是不是也在崩溃循环里：
# 看有没有卡住的更新状态
ls ~/Library/Caches/com.todesktop.230313mzl4w4u92.ShipIt/
# 有的话直接清掉
rm -rf ~/Library/Caches/com.todesktop.230313mzl4w4u92.ShipIt/update.*
rm -f ~/Library/Caches/com.todesktop.230313mzl4w4u92.ShipIt/ShipItState.plist
# 禁用自动更新
defaults write com.todesktop.230313mzl4w4u92 SUEnableAutomaticChecks -bool false
更新手动去官网下，至少你能盯着 Activity Monitor 的 Disk IO 曲线，见势不对直接 kill。
硬件：MacBook Pro M3 Max / 36 GB / macOS 26.3
Cursor：2.6.20
更新框架：Squirrel（Electron 标配的 ShipIt）
死机类型：Apple Silicon Watchdog Reset（不是 kernel panic，比那个更严重------内核跑不到 panic 流程就硬死了）
1 个帖子 - 1 位参与者