Mac 在 VPN 唤醒后死机：该记录些什么

关于唤醒后 Mac 死机的报告，常把三种故障混成一句抱怨。指针可能还能移动，但 VPN 客户端不响应点击；客户端可能正常，但某个远程会话超时；也可能整个桌面都不再接受输入。每种情况需要的证据不同，而死机后的第一分钟就决定了你面对的是哪一种。猜错方向，后面每一步都会走偏。

什么停止了响应，什么只是停止了等待

先做成本最低的测试：移动指针并在本地文本框里输入，打开客户端自己的状态界面读取它报告的状态，然后在私有应用里新建一个操作，而不是继续原来的会话。在碰其他任何东西之前先把这三个答案写下来，因为失败的先后顺序是人们最先忘掉的细节。

每种结果指向不同位置。单个会话卡住时，证据在隧道另一端，Mac 只是旁观者。桌面还能用而客户端不响应点击时，排查范围就缩小到那个进程及其日志。指针完全不动时，连运行任何检查命令的前提都没了，因为每条命令都需要一个能响应的 shell。

即使用户用一句话概括，也要把三种情况分开。你提交的报告应说明哪个测试先失败、哪些仍然通过，而不是笼统地说机器死机了。正是这种区分，让支持工程师能判断该看网络、客户端还是硬件。

明天仍然站得住的时间线

时钟是记录中事后无法重建的部分。记下合盖或唤醒的时刻、第一次失败操作的时刻，以及这两个时刻相隔的是几秒还是几分钟。然后写清 Mac 是真睡着了，还是只锁了屏幕，因为这是两种不同状态，唤醒路径也不同。睡眠日志是这条时间线中事后唯一能核对的部分。

pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compact

第一条命令把模糊的记忆变成一个时间戳，你可以把它填进第二条命令。把日志查询限定在客户端进程和一个短时间窗内，你得到的是一页输出，而不是一整天的量。趁屏幕还在眼前，把机型标识、客户端构建版本和所用网络抄进同一条笔记；第二天早上再拼的报告会丢掉让它可读的顺序。

选择与症状相符的采集方式

Apple 在 Activity Monitor 诊断指南 中记录了三采集方式，它们回答不同的问题。Sample Process 观察一个选定的进程三秒，spindump 针对一个已停止响应、即将被强制退出的应用，System Diagnostics 则把系统日志收进一个包。

按观察到的现象选，而不是按习惯选。能运行但行为异常的客户端，用 sample <pid> 3 -file ~/Desktop/sample.txt 或从齿轮菜单取样。一直转圈、必须被杀掉的应用，从同一菜单选择 Spindump。同时涉及客户端和系统的问题，用 sudo sysdiagnose -f ~/Desktop。能先取样就不要先强制退出，因为终止恰好会毁掉你想检查的状态；文件名按事件和时间来取，不要按你对原因的猜测来取。

把每个包都当作敏感数据。这些报告带有账户名、主机名、路径和网络细节，所以要通过组织使用的支持渠道发送，而不是附在公开帖子里。如果必须删减报告，就删副本，原件保持完整。

当指针本身不动时

界面完全失效会改变操作顺序。你无法从不响应的 shell 里取样或查询，所以第一目标是恢复，第二目标才是记录。强制重启有时是唯一出路，而那也正是最有用的细节消失的时刻。重启前记下时间、开着的窗口，以及菜单栏网络图标是否显示连接；这些观察能跨过重启，进程状态则不能。

机器回来后，不要认定重启已经找到了元凶。它只恢复了服务，没有指认任何东西。只有每次只改一个受控条件去复现，才能指向某个组件。

如果死机再次出现，每次只改一个条件：网络、客户端版本或睡眠模式。先保存远程工作，不要在生产力机器上反复强制睡眠，因为反复的硬循环有数据丢失风险，而且往往产生与你追查的不是同一个故障。把每次尝试连同条件记下来，下一次才可比较，而不是只留下传闻。

交接的是一件事，不是一种情绪

能推动处理的交接要说清四件事：什么停止了响应、何时发生、当时网络是什么状态、哪次采集覆盖了那个时间窗。再加上客户端版本和 macOS 构建版本，然后停。平台团队和客户端厂商都能据此行动，而两者都无法对一段沮丧的描述采取行动。把记录放在一处并持续追加，而不是每次重新讲一遍故事；如果某次更新改变了行为，要写明是哪一次，因为那也是证据。

好的记录还会说明你已经排除了什么。如果死机期间本地应用有响应，就写明；如果睡眠日志显示的是真正唤醒而非锁定，也写明。下一个人不该重复你已经做过的测试。

关闭工单前核对三件事：时间戳来自睡眠日志而不是记忆，采集方式与实际看到的症状相符，报告包放在获准的位置。三者缺一，报告就还不能发。