活动监视器不直接显示I/O等待时间，但可通过磁盘视图中“读取字节/秒”“写入字节/秒”与“读取次数/秒”比值、CPU标签页内核占用异常升高及菜单栏能量提示等交叉判断高I/O延迟瓶颈。
macos 终端开发环境本身轻量，但实际运行中常因配置不当、后台服务或工具链滥用导致 cpu、内存、磁盘 i/o 异常升高。问题往往不来自终端应用（如 terminal 或 iterm2），而是它所启动的 shell 进程、加载的脚本、调用的工具或关联的守护进程。
看 CPU：揪出“系统时间”过高的真凶
终端环境高 CPU 占用，常见于 shell 初始化慢、自动补全卡顿、别名/函数逻辑错误或后台任务失控。关键不是看“用户时间”，而是“系统时间”：
- 在活动监视器 → CPU 标签页，启用“显示” → “列” → 勾选“用户时间”和“系统时间”
- 排序“系统时间”，若 zsh / bash 进程的系统时间远高于用户时间（比如 80% vs 20%），说明大量时间花在内核态：可能是频繁 fork 子进程（如每次提示符都执行 git status）、权限检查（如 ~/.zshrc 中误用 sudo）、或文件系统元数据访问（如 Spotlight 正在索引你的 dotfiles 目录）
- 临时验证：新开一个纯净终端（不加载任何配置），运行 zsh -f，再执行 top -o cpu 对比——若 CPU 明显下降，问题就出在 ~/.zshrc 或相关配置中
查内存：警惕 dotfiles 和插件的隐形开销
看似简单的配置文件，叠加后可能引发显著内存压力：
- oh-my-zsh、powerlevel10k 等框架本身会加载数十个插件和主题，部分插件（如 git、kubectl、nvm）会在每次命令执行时触发子进程或读取大文件，增加联动内存（Wired Memory）占用
- 在活动监视器 → 内存标签页，开启“显示” → “列” → 勾选“内核内存”，观察 zsh 进程是否持续增长；同时留意“压缩内存”是否异常高——这常是 shell 启动了过多子 shell 或未释放缓存所致
- 避免在 ~/.zshrc 中直接执行耗资源命令（如 git status、node --version），改用异步提示符（如 p10k 的 `prompt_subst` + `async` 模式）或延迟加载
盯磁盘与能耗：识别索引、同步与日志干扰
终端操作常触发后台 I/O，尤其当你把项目、dotfiles 或 SDK 放在 iCloud Drive 或 Dropbox 同步目录下：
- 在活动监视器 → 磁盘标签页，开启“等待 I/O”列，若 zsh 或 mdworker 进程长期处于高“等待 I/O”状态，说明文件系统正被 Spotlight 或同步服务阻塞
- 切换到“能耗”标签页，排序“12 小时能耗”，查看 terminal、iTerm2 或 mds_stores 是否排前列——高能耗 + 高等待 I/O 是典型“配置即服务”反模式（例如在 ~/.zshrc 中调用 curl 检查更新、或用 fzf 实时搜索整个 $HOME）
- 将 dotfiles 仓库（如 ~/.zshrc 所在目录）从 iCloud Drive 移出，并在系统设置 → Apple ID → iCloud → iCloud Drive → 选项中取消勾选“桌面与文稿文件夹”，可大幅降低后台磁盘争用
终端专属诊断命令组合
比图形界面更快定位问题：
- top -o cpu -s 2：每 2 秒刷新，聚焦 CPU 占用最高的进程，确认是否为 zsh、bash 或其子进程（如 git、npm、python）
- lsof -p $(pgrep -f "zsh") | wc -l：统计当前 zsh 进程打开的文件数，超 500 通常意味着插件或 alias 过度扫描目录
- vm_stat | grep "Pages free\|Pages active"：快速查看空闲页与活跃页比例，若空闲页持续低于 1000，配合高“压缩内存”，说明 shell 衍生进程正在吃掉物理内存
- sudo fs_usage -w -f filesystem | grep -E "(zsh|Terminal|iTerm)"：实时捕获文件系统调用，可发现隐式读取（如 oh-my-zsh 插件反复 stat .git/config）
