VPN 工作完成后再关 Mac，而不是之前

两个人下班后关同一台 Mac，结果却不一样。一个丢掉了已完成九成的上传；另一个二十秒后合上盖子，一切都已落盘。差别不在运气或磁盘速度。差别在于他们关闭私有会话、共享和隧道的顺序，以及是否有东西在等待这些步骤完成。

下面的比较是「先断隧道」与「先收尾」之间，因为这一个选择就解释了大多数糟糕结果。

两种关机顺序，两种结果

先断隧道看起来干净：VPN 菜单点「断开」，图标消失，然后用户关闭文档并关机。问题在于，断开可能在应用写完之前就撤掉路由和已挂载的共享，正在进行的上传无处可去。用户看到干净的断开，以为其余都安全。图标消失并不能说明应用是否完成。随后的关机照常进行，走的却是一条不再承载应用所需流量的网络路径。

先收尾要慢几秒，也平静得多。私有操作完成，共享被有意卸载，之后隧道才消失。接下来的关机已经没有什么可打断的了。

为什么共享必须先于隧道

已挂载的网络共享是活依赖，不是普通文件夹。客户端握着未关闭的句柄，服务器跟踪租约，仍在队列里的写入属于这个会话。在它下面强行抽走隧道，就会出现经典的失效挂载：Finder 显示共享，任何访问都卡住，唯一的解法是强制卸载，有时还要重新登录。

等文件活动停止后，用受支持的操作卸载。在 macOS 上，就是 Finder 里的推出按钮，或对挂载点有意执行 diskutil unmount，而不是断开底层网络。然后先在侧边栏确认共享已消失，再动 VPN。

如果共享拒绝卸载，说明还有东西占着文件。找到它、关闭它，再试一次。拒绝是信息；强制卸载会把它变成数据丢失。

停止掌管会话的客户端

VPN 会话有所有者，只有所有者才能干净地停止它。Tunnelblick 的连接要通过 Tunnelblick 停止。原生配置要通过系统自身的控制或其管理应用停止。用另一个 OpenVPN 二进制去连同名配置并不能停止应用管理的会话，还可能留下两个进程争论谁持有隧道设备。

留意自动恢复。On Demand 规则或受管理的配置可能在有意停止几秒后重新拉起连接，看起来像客户端无视命令。那是策略而非缺陷，应当与策略的所有者解决，而不是用一个不断断线的辅助脚本去对抗。

有些客户端把「请求断开」和「拆除完成」分开。如果流程要等完成，就读取客户端自身状态并给出有限期限。随意睡一秒不是等待，杀掉所有名字像 VPN 的进程也不是拆除。

别碰操作系统自己的关机

最后一步应当是普通关机：Apple 菜单、键盘快捷键或计划好的 shutdown 命令。这条路径会让应用保存、询问未保存的工作，并按预期顺序卸载卷。它也是失败时能被别人调试的那条路径。

强制断电跳过了这一切。机器真的卡死时它是对的，作为赶截止时间的日常手段它就是错的。强制关机丢掉上传并不比等待更快，只是把代价挪到第二天早上。

Apple 的关机指南划出了这条界线，并单独描述强制情形。把它读成修正顺序的理由，而不是让强制关机进入日常流程的许可。

把截止时间写进计划

如果 Mac 必须在固定时间关机，就在用户会话还活着时开始准备。拖到最后一刻才清理，正是 MFA 提示、未完成的写入或顽固挂载变成事故的方式。给流程一个开始时间，而不只是结束时间。

确定某一步超出预算时怎么办。选项是通知用户、取消关机，或按另一套已批准的流程处理。把「清理花太久」悄悄升级成强制断电，是唯一必定导致所有人想避免的那种结果的选项。

写下来，规则很短：完成私有工作，关闭依赖的会话，通过所有者停止隧道，然后正常关机。四步，按这个顺序，每一步都带截止时间。