安装安全

正因为安装过程由自己掌控，这些检查才有可能实现。每一项检查针对的，都是软件在你的 Mac 上替换另一个软件时可能出错的地方。

它从不强制退出正在运行的应用

安装器本身从不退出任何应用。重新启动一个已更新的应用是单独的一步，默认开启，可以在“设置”里关闭⁠——真正执行时，退出只是一次普通的 terminate() 调用。应用会照常弹出自己的保存提示，也可以拒绝退出。拒绝退出的应用会继续运行，并保留一个重新启动按钮，所以未保存的工作永远不会因为被强制退出而丢失。

值得了解的是：重新启动发生在新版本已经落盘之后。所以如果你拒绝了退出，磁盘上就会有一份已更新的应用包，旁边是一个仍在运行旧代码的进程，直到你自己重新打开它为止。这正是那一行上“重新启动”按钮的含义。

替换任何东西之前的五项检查

EdDSA，在应用自己提供了公钥的情况下进行校验。有些厂商发布的是未签名的订阅源；这些不会被直接拒绝，只是需要靠剩下的检查自己过关。而确实公布了密钥的应用，则必须提供有效的签名⁠——下文有一个刻意设计的例外。

然后，无论来自哪个源，都会对下载到的应用包执行四项检查：

• Developer ID 签名，严格校验到底⁠——每一种架构、包括嵌套代码在内，而不只是最外层的应用包。
• Team ID，必须与被替换的应用一致。
• Bundle identifier，取自签名而不是 Info.plist，所以被改写过的 plist 蒙混不过去。
• 可运行架构，从真实的 Mach-O 切片中读取。这台 Mac 无法启动的版本会被拒绝，而不是装上之后才发现坏掉。

下载结果如果指向另一个开发者，会被拒绝，而不会被安装。

例外情况是：当厂商更换了签名密钥、却没有发布过渡版本时，旧密钥就再也无法校验它发布的任何东西了。与其让应用永远卡在这里，无效的 EdDSA 签名会被记录下来而不是直接抛出，只要其余四项检查都通过，并且下载到的应用包带有一个能校验该订阅源的新密钥，安装仍然可以继续。这种情况下，真正承担信任的是 Developer ID 和 Team ID 这两道关卡。

大版本升级需要你先确认

跳到一个新的大版本时，会先弹出警告，而不是直接给一个一键按钮，因为对商业应用来说，这可能需要一份新的许可证。这个决定由你来做；DuoUpdater 不会把它做成一键了事，悄悄替你拍板。

安装前会立即重新检查一切

一份打开了一个小时的清单已经过时了。在替换之前，检查会再跑一遍，所以不会对一个在此期间已经被别的东西更新过的应用，多此一举地重复安装。

用于回滚的备份

被替换的应用包会被保留下来，可以放回去。duo backups 可以从命令行列出这些回滚点；应用里也提供同样的功能。

重新启动检测

如果一个应用在磁盘上已经更新，但正在运行的还是旧版本⁠——这是通过 LaunchServices 比对得出的，不是猜的⁠——它会显示一个重新启动操作，而不是被报告为已是最新。磁盘上的版本和正在运行的版本是两个不同的事实，这一行会告诉你哪一个已经过时。