Mac 上的 dasd 是什么？

最后更新: 2026-07-31

它是什么

dasd 是 Apple 的 Duet Activity Scheduler 后台守护进程。系统通过 launchd 启动和管理它。对应服务标识是 com.apple.dasd，可执行文件位于 /usr/libexec/dasd。

不少后台工作并不需要立刻执行。App 或系统服务可以先登记一项可延期活动，再由 dasd 判断什么时候适合开始。它会参考电源状态、设备温度、用户是否正在操作，以及当前网络条件。条件合适时，它允许提交任务的一方开始工作；条件不理想时，则继续推迟。

所以，dasd 更像一个多个客户端共用的调度中心，但不要把这个说法理解成它包办了所有后台工作。它不是 Time Machine，也不是 Spotlight、iCloud 或某个特定同步服务。这些服务可以提交任务，也可能参与任务执行，但它们和 dasd 不是同一个东西。真正备份、索引、同步或下载数据的，通常另有对应进程。

它为什么要联网

有些后台活动明确要求网络。例如，任务可能声明只要网络可用即可，也可能要求廉价网络或不受限网络。遇到这类活动，dasd 会观察当前是否联网，并参考连接成本、连接质量等条件，判断现在启动还是稍后再做。

任务获准执行后，连接对象取决于任务是谁提交的。它可能涉及 iCloud 或 CloudKit，也可能连接 Apple 的内容服务、更新服务，或者第三方 App 自己的服务器。只看到 dasd 这个进程名，无法反推出远端是谁，更不能据此判断传输了什么内容。

Apple 展示过一个 CloudKit 场景：dasd 负责批准并触发后台活动，真正执行导出的则是 App 进程和 cloudd。当前 macOS 的 LaunchDaemon 配置中，也能看到要求网络连接或廉价网络的 dasd 周期活动；它的可执行文件还使用了 Network framework。

不过，公开资料没有交代所有内部路径。某些周期活动是否包含 dasd 自己发起的远程传输、会连接哪里、具体传什么，目前都没有得到完整核实。可以确认的是：在通用后台任务中，dasd 主要负责判断时机，数据主体通常由被触发的进程传输。不能进一步写成“dasd 绝对不会传任何数据”。

正常流量应该是多少

目前没有一个可信的正常值。Apple 没有公布 dasd 的流量区间，也没有可靠的独立测试能给出每天多少 KB、多少 MB 之类的标准。任何具体数字都缺少依据，不能拿来当判断异常与否的门槛。

从公开架构看，dasd 本体通常以间歇性调度和网络状态协调为主。它触发的备份、同步、内容抓取或系统更新，流量可能大得多，但主体数据往往记在客户端 App、cloudd 或其他传输服务名下。调度者触发了一项工作，并不代表这项工作的全部数据都由调度者发送。

反过来，也不能因为它主要负责调度，就认定它的直接流量必然为零。Apple 没有公开全部内部活动，现有证据不足以支持这种绝对结论。如果统计工具长期记录到 dasd 大量传输，仅凭进程名仍然无法确定内容和原因。更有价值的线索是活动标识、发生时间，以及同一时段有哪些客户端进程被启动。

能不能关掉

结论是保留 dasd。Apple 没有提供专门关闭它的系统设置路径，也没有受支持的总开关。

强制结束进程、阻断它，或者修改对应 LaunchDaemon，都可能破坏多个客户端共用的后台调度。系统维护、内容刷新、CloudKit 导出、备份和更新活动可能因此推迟，严重时会直接失败。究竟影响哪些任务，取决于 macOS 和已经安装的 App；Apple 没有公布完整清单。

长期 kill 也未必有效，因为 launchd 可能再次启动 dasd。系统保护机制还可能阻止相关修改。如果它出现异常 CPU 占用、磁盘读写、频繁唤醒或可疑网络活动，应该先从活动标识追查真正的任务提交者。更新或重启 macOS，也比拆掉共享调度服务稳妥。

关闭“登录项”或某个 App 的“允许在后台”项目，同样不能关闭 dasd。这些设置只管理相应 App 的后台项目，并不是 com.apple.dasd 的总开关。

常见的误解

• “dasd 是 Desktop and Search Daemon。” 这个名称不对。Apple 的历史手册把它定义为后台活动调度守护进程。Spotlight 的主要索引工作由其他进程完成，不能因为名称猜测就把两者画上等号。

• “dasd 就是 Time Machine、iCloud 或 Spotlight。” dasd 是通用调度器，多个系统组件和 App 都能使用它。Time Machine、iCloud、Spotlight 可以提交或参与后台活动，但其中任何一个都不等于 dasd。

• “唤醒记录里出现 dasd，说明记录中的工作和流量全是它产生的。” 这类记录通常表示 dasd 代表某个客户端安排了执行或唤醒。客户端有自己的活动标识，获准运行后还会调用其他进程。看到调度记录，不等于找到了所有实际工作和全部流量的归属。

• “dasd 自己绝对不会传数据。” 现有证据不足以支持“绝对不会”。公开的 CloudKit 案例确实把主要传输归到 App 和 cloudd，但当前 dasd 也包含受网络条件约束的活动和网络相关组件。Apple 没有公开所有内部路径。比较稳妥的结论是：它不是通用后台任务的主要数据载荷进程，但不能断言直接传输永远为零。

• “把登录项或 App 后台活动关掉，就能关闭 dasd。” 登录项和后台活动设置管理的是对应 App，不是系统 LaunchDaemon com.apple.dasd。Apple 没有提供一个设置项来统一停掉 dasd。

• “删除 plist、反复 kill 或禁用 dasd，是没有副作用的省电办法。” 这些操作会影响共享后台调度。依赖它的维护、刷新、导出、备份或更新任务可能延迟或失败。系统保护可能阻止修改，launchd 也可能重新启动它。发现 CPU、磁盘、唤醒或网络异常时，应先根据活动标识查提交者，再考虑更新或重启系统。

• “看到 dasd 就说明 Mac 中了恶意软件。” /usr/libexec/dasd 中代码标识为 com.apple.dasd 的实例属于 Apple 系统组件。若同名文件出现在别的目录，情况就不同了，需要单独核验代码签名和文件来源。进程名称相同，不代表身份也相同。

怎么看它到底用了多少

下一步是按进程查看同一时段的流量，把 dasd 与客户端 App、cloudd 及其他传输服务放在一起比较。Bytetally 的逐进程历史可以提供这份记录，但不能代替对活动来源的判断。结合发生时间和活动标识，才能继续缩小到真正提交任务的一方。

相关进程

常见问题