只为一项 VPN 任务让 Mac 保持唤醒，而不是为整个 VPN

你需要在离开时让一次传输完成，而 Mac 进入睡眠是最明显的嫌疑。caffeinate 可以恰好在那段时间内持有一个电源断言，而且它比初看时显得更狭窄。它在命令运行期间阻止空闲睡眠；它不会让 VPN 会话保持存活，也无法挽救因凭据在午夜过期而中断的传输。知道它的作用边界在哪里，才能避免把下一次故障归咎于错误的层面。

这个断言究竟持有什么

该工具请求电源管理系统在被包裹的进程存活期间保持一个断言打开。进程退出时，断言也随之消失。这段生命周期才是有用的部分：你不是在切换一个整机设置，然后指望以后记得撤销它。

这些标志选择不同的断言。-i 阻止系统空闲睡眠。-d 针对显示器睡眠，-s 则在系统允许的情况下针对系统睡眠。它们都不是「保持唤醒」的全面承诺，也都不能解锁屏幕或对抗合盖。请选择与你实际看到的中断相匹配的那一个。

当有人报告 Mac「还是睡了」时，这个区别就很重要。问题在于请求的是哪种断言、持续多久，以及是什么事件导致了睡眠。电源管理会评估多种输入，而一个断言只覆盖其中一种。

包裹任务，而不是装饰会话

caffeinate -i /usr/bin/ssh [email protected]

这会在 SSH 客户端运行期间保持空闲睡眠断言，而这正是包裹而不是放到后台的全部意义。VPN 配置文件未被触碰，不会发送任何 keepalive，隧道的配置也没有任何改变。

对于有界的时间窗口，时长标志才是诚实的做法：

caffeinate -i -t 1800

任务提前完成时，用正常的打断方式停止那次调用。不要把一堆包裹进程留在后台，然后事后靠杀掉所有同名进程来清理；你会连想保留的东西一起干掉。

睡眠是原因之一，而非原因

阻止空闲睡眠只是从清单上移除了一种中断。它不能覆盖有意的睡眠命令、合上的盖子、断电或管理员设置的政策。这些是彼此独立的决定，指望用户级断言能胜过它们，正是人们得出「这工具没用」结论的原因。

显示器睡眠和屏幕锁定也是分开的。Mac 可以在显示器关闭时保持唤醒，也可以在任务继续时锁定。如果要求的是屏幕亮着，那是另一个标志；如果要求的是屏幕解锁，没有任何标志能提供。选开关之前，先说清你真正需要这三种结果中的哪一种，因为它们并不是同一行为的不同名称。

VPN 会话有自己的时钟

IPsec 或 TLS 隧道按端点约定的时间表重新协商密钥，而服务器可以无视客户端活动强制执行最长会话寿命。凭据会过期。接入链路可能因与笔记本是否唤醒毫无关系的原因而断开。这些都不关心电源断言。

因此，当 Mac 明显醒着而有用流量失败时，延长时长既不是解释也不是修复。请读懂故障：密钥协商错误、认证过期和载波丢失在隧道日志里看起来各不相同，各有各的修法。

把持久性放在远端主机上

如果失去本地连接会浪费数小时的工作，答案就在另一端。终端复用器在 SSH 断开时让服务器上的会话保持存活，作业系统在会话结束时让工作继续。两者都不依赖笔记本的电源状态。

那是另一条故障边界，而对长任务来说重要的正是它。只有两者都成立时才把二者结合：机器必须为工作的本地部分保持唤醒，远端部分必须经受住断连。然后从第二个终端重新连接，确认任务仍在运行来验证。

写下你用了哪个断言，以及它何时结束。短期的运维选择没问题；没有解释的长期选择会在六个月后变成一张支持工单，因为没人记得 Mac 为什么从不睡眠。