活动监视器不能直接标记“网络超时”或“假死”，但可通过网络标签页中收发流量停滞、CPU长期为0且状态为sleeping、响应性显示“无响应”、取样堆栈频繁停留于recvfrom/connect等系统调用，结合lsof/dtruss验证，识别因网络等待卡住的假死进程。
活动监视器本身不直接标记“网络超时”或“假死”，但它能帮你识别出因等待网络响应而卡住、不再活跃却持续占用资源的进程。关键不是看它有没有联网，而是看它是否在挂起状态中消耗 cpu、内存或阻塞系统调度。
重点关注网络标签页中的异常停滞现象
打开活动监视器 → 切换到“网络”标签页，观察“接收的数据/秒”和“发送的数据/秒”两列：
- 若某进程长期显示“0 B/s”，但“收到的数据”或“发送的数据”总量有明显数值（比如几 MB 以上），说明它曾发起过连接，之后就再无收发——可能是卡在 connect() 或 read() 等系统调用上
- 同时检查该进程在“CPU”标签页中的“% CPU”是否持续为 0.0，且“状态”列为 “sleeping” 或 “idle”，但“启动时间”很早、已运行数小时，这种“活着却不干活”的状态就是典型假死信号
结合进程状态与能耗列交叉判断
右键点击列标题 → 勾选“状态”“CPU 时间”“能耗”“响应性”（macOS Sequoia 起新增）：
- “响应性”一栏若显示“无响应”，哪怕进程没弹出强制退出窗口，也代表它已无法响应系统事件（如鼠标点击、菜单展开）
- “能耗”值偏高但“% CPU”极低，常见于进程在内核态反复轮询或陷入不可中断睡眠（D 状态），多由驱动或网络栈异常引起
- “CPU 时间”增长缓慢甚至停滞，而进程存活时间很长，说明它基本没执行有效指令，只是占着 PID 和资源
用“取样进程”确认是否真卡在网络 I/O 上
选中可疑进程 → 顶部菜单栏点“文件”→“取样进程”（或右键 → “取样”）：
- 取样结果里若频繁出现
recvfrom,sendto,connect,poll,select,kevent等系统调用，且堆栈停留在libsystem_kernel.dylib或libnetwork.dylib内部，基本可断定卡在网络等待 - 如果取样中看到大量
mach_msg_trap或__psynch_cvwait，则更可能是线程被同步原语阻塞，而非纯网络问题，需进一步排查是否服务端未返回 ACK 或 TLS 握手僵死
辅助验证：终端命令快速筛出疑似挂起连接
打开终端，运行以下命令缩小范围：
-
lsof -iTCP -sTCP:SYN_SENT,ESTABLISHED,TIME_WAIT | grep -v "127.0.0.1"查看是否有大量半开连接（SYN_SENT）或长时间未关闭的 ESTABLISHED 连接 -
netstat -an | grep "TIME_WAIT\|CLOSE_WAIT" | wc -l若 CLOSE_WAIT 数量持续高于 200，说明进程没主动 close socket，容易堆积成假死 -
sudo dtruss -p [PID] 2>&1 | grep -E "(connect|recv|send|poll|select)"（需输入密码）实时跟踪该进程的网络系统调用行为，看是否卡在某一步不动
假死进程往往不会立刻崩溃，但会拖慢 Dock 响应、菜单弹出、Spotlight 搜索等全局交互。发现后先尝试正常退出；若无效，再强制退出，并留意是否同一应用反复出现该现象——这往往是客户端网络错误处理缺陷，不是系统问题。
