活动监视器不直接显示系统中断详情，但可通过 kernel_task 异常高占用、cpu 历史锯齿脉冲、系统态占比过高及低磁盘读取等特征间接识别中断压力。
活动监视器本身不直接显示“系统中断”（如硬件中断、软中断、定时器中断等）的占用详情，因为 macOS 不向用户态工具暴露中断计数器或 per-interrupt CPU 时间——这与 Linux 的 /proc/interrupts 或 Windows 的性能计数器不同。但你可以通过观察 kernel_task 的异常行为、CPU 时间构成和系统级线索，间接识别中断相关压力是否正在拖累 CPU。
看懂 kernel_task 是关键入口
kernel_task 在活动监视器中不是普通进程，它是内核调度器、中断处理框架和电源管理逻辑的聚合体现。当它持续占用 60% 以上 CPU，且没有对应高负载应用时，很可能是以下中断类问题在起作用：
- 某个 USB/雷电外设（如扩展坞、未认证摄像头）频繁触发硬件中断，导致内核不断响应
- 网卡驱动异常（尤其使用第三方驱动或虚拟网卡时），产生大量网络收包中断
- 固态硬盘响应延迟或 SMART 报错，引发 I/O 中断风暴
- 蓝牙模块固件卡死，持续轮询状态并生成中断请求
用 CPU 历史记录识别中断特征波形
中断密集型负载常表现为高频、短促、规律性强的 CPU 尖峰，不同于应用进程的持续占用。操作方式如下：
- 打开“窗口” > “CPU 历史记录”，让图形持续显示 30 秒以上
- 若看到密集的锯齿状脉冲（每 1–5ms 一次，幅度不均但节奏稳定），高度提示硬件中断活动异常
- 同步打开“磁盘”标签页，若“读取/秒”数值极低但 kernel_task 高占，更倾向是中断而非 I/O 本身
交叉验证：结合系统指标缩小范围
单看 CPU 列表容易误判，需联动其他维度确认是否为中断驱动：
- 切换到“能量”标签页：检查“能效影响”列为“高”的进程，尤其是 mds_stores、trustd、coreaudiod —— 它们被中断唤醒后可能放大 kernel_task 负担
- 查看“CPU”底部状态栏：“系统”占比显著高于“用户”，且“闲置”长期低于 5%，说明大量时间花在内核态（含中断上下文）
- 在“所有进程”视图下启用“PID”列，按 PID 排序；中断处理线程通常 PID 较小（
轻量排查与确认手段
无需重装系统或深入 dtrace，以下几步可快速验证中断是否为元凶：
- 拔掉所有非必要外设（特别是 USB-C 扩展坞、HDMI 转接器、蓝牙耳机），观察 kernel_task 是否 10 秒内回落至 10% 以下
- 重启 Mac 后立刻打开活动监视器，不做任何操作等待 60 秒 —— 若 kernel_task 从开机起就缓慢爬升，大概率是某个内建控制器（如 T2/M系列芯片的协处理器）通信异常
- 终端运行 sudo powermetrics --samplers smc | grep -i "cpu\|temp"，观察是否存在温度骤升伴随 CPU 频率锁定，这是温控中断介入的典型信号
