活动监视器不显示磁盘写入等待队列，但可通过“写入次数/秒”与“写入字节/秒”比值判断小写放大、vm_stat观察Pageouts激增、fs_usage定位高频写入路径来识别写入队列积压。活动监视器不直接显示“磁盘写入等待队列（Wait）”这一指标，macOS 未向用户层暴露类似 Linux 的 `iowait%` 或 `await`（毫秒级平均等待时长）等内核级 IO 调度队列参数。但你可以通过观察**磁盘行为模式、进程级 IO 特征与系统响应状态的交叉异常**，有效识别和定位写入请求在队列中积压、延迟响应的典型场景。
看磁盘页中的“次数/字节”比值，判断是否陷入小写放大
打开活动监视器 → 切换到“磁盘”标签页，右键表头启用以下列：读取次数/秒、写入次数/秒、读取字节/秒、写入字节/秒。
- 若“写入次数/秒”持续 >800，但“写入字节/秒”仅 1–5 MB/s，说明大量 小块随机写入（如日志追加、数据库 WAL、Spotlight 元数据更新），极易填满 SSD 写入缓冲区，触发后台合并（GC）并拉长队列等待；
- 计算平均单次写入大小：用“写入字节/秒” ÷ “写入次数/秒”。若结果
- 注意“写入字节”累计值在无操作时突增（如 10 秒内+300 MB），而速率列未同步飙升——这常是 APFS 快照合并或 Time Machine 本地快照刷盘所致，背后有内核级写入队列调度，用户态不可见但真实存在等待。
结合 CPU 页与能耗页，识别内核层阻塞源头
高写入等待往往不表现为 CPU 占用高，而体现为“系统”或“内核任务”占用率异常抬升（>30%），同时用户进程 CPU 很低（
- 在“CPU”页底部留意“系统”栏数值：若它持续偏高，且与“磁盘”页中高 IOPS 进程（如 mds_stores、cloudd、backupd、kernel_task）时间上强重合，说明文件系统或驱动正在处理阻塞型写入请求；
- 切换到“能耗”页，重点关注“防止睡眠”列为“是”的进程——这类进程会强制维持磁盘通道活跃，即使没有实际写入任务，也会抑制系统进入低功耗 IO 调度模式，间接延长队列等待窗口；
- 按住 Option 键点击菜单栏电池图标，查看“使用大量能量”的应用列表。若与活动监视器中高“写入次数/秒”的进程一致（如某 Electron 应用、OneDrive 同步服务），大概率是其频繁调用
fsync()或强制落盘导致写入排队。
启用分层进程视图，追踪写入链路源头
单一进程的写入统计容易掩盖真实压力来源，需展开父子关系确认是否为子进程密集发起写入。
- 在活动监视器“显示”菜单中选择“所有进程，分层显示”；
- 找到可疑父进程（如 mdworker_shared），点击左侧三角展开，观察其子进程（如 mds_stores）是否在“磁盘”页中持续贡献高“写入次数/秒”；
- 右键目标进程 → “在 Finder 中显示”，确认路径是否属于系统服务（如
/System/Library/CoreServices/）或第三方插件（如/Library/QuickLook/），避免将正常索引行为误判为故障； - 若怀疑是云同步工具（iCloud Drive、Dropbox），可临时退出后观察“写入次数/秒”是否骤降——这类应用常边下载边解压边写入，形成 IO 放大效应，显著拉长写入队列。
用终端命令补足活动监视器盲区
当界面工具不足以量化延迟时，终端可提供更底层线索：
- 运行
iostat -x 1（macOS 13.3+）：关注 await 字段（单位 ms），持续 >30 ms 表示磁盘响应已成瓶颈，写入请求在队列中明显积压； - 运行
vm_stat 1：观察 Pageouts 是否激增（>100/sec）。频繁换页会触发大量后台写入，加剧写入队列压力； - 运行
sudo fs_usage -f filesys | grep 'write'：实时捕获哪些路径被高频写入（如/Users/xxx/Library/Caches/或/private/var/folders/），直接定位写入源头，而非依赖活动监视器的聚合统计。
