macOS 27 夜间 dasd 与 appstoreagent CPU 占用过高：修复方法

你在电池状态良好的情况下合上屏盖，早上却发现 Mac 摸起来发热，风扇明显工作过，电量掉得比一整晚睡眠应有的损耗多得多。如果这一切是在升级到 macOS 27 Golden Gate 之后才出现的，那么有一个明确且有大量记录的嫌疑对象：两个名为 dasd 和 appstoreagent 的后台进程陷入紧密循环，据报道每晚从午夜开始。本文将说明这两个进程是什么、Apple 的后台调度器如何决定它们何时运行、如何证明你遇到的正是这个 bug（而不是让 Mac 夜间发热的其他六七种原因之一）、社区给出的具体解决方法及其撤销方式，以及关于 macOS 27.0.1 是否修复了该问题，我们能说什么、不能说什么。本文所有内容均来自公开报告和文档；凡是未经证实的地方，我们都会明确指出。

核心要点

• 该 bug 已有报告，多位用户可复现，但 Apple 尚未确认。 MacRumors 上 9 月 27 日发起的一个帖子描述了两台 MacBook 上 appstoreagent 与 dasd 在午夜飙升的情况，其他成员也在 Mac Studio 和 MacBook Pro 上报告了同样现象。Apple 尚未发布相关的已知问题说明。
• 据报道，起因是一个始终不更新自身截止时间的 Apple Arcade 任务。 独立的分析文章称，com.apple.appstored 中名为 ArcadePayoutResetDate 的偏好设置一直停留在过去，导致调度器不断重新运行该任务，据称每秒 70 到 100 次。
• 你可以在两分钟内完成确认，且无需更改任何设置。 按 CPU 排序进程、读取该偏好设置，再用谓词查看统一日志。如果日期早于当前时间且日志被刷屏，那就是这个 bug。
• 社区修复方案是一条 defaults write 加上 killall appstoreagent。 它会把日期推到未来。这只是权宜之计，可以撤销，据报道在你所设日期（例如七天）内有效。
• 我们无法证实 27.0.1 已修复此问题。 Apple 的 27.0.1 更新（版本号 26A434）被描述为修复了未具体说明的 bug。目前还没有人发布关于此问题的确认结果，所以请在自己的 Mac 上测试，而不要想当然。
• 先排除常见的“正常”原因。 升级后的 Spotlight 与照片分析、时间机器、iCloud 同步以及网络唤醒设置，都会造成夜间发热，下方的判断表会告诉你哪个进程名对应哪种原因。

症状：早上 9 点，Mac 发烫、电量不见了

MacRumors 帖子的楼主对这种现象给出了最清晰的描述。自安装 macOS 27 以来，他们看到 CPU 占用「恰好在午夜」飙升，元凶是 appstoreagent 和 dasd，MacBook Pro 和 MacBook Air 上都是如此。第二次，他们让两台机器整夜开着并打开 iStat Menus，负载在早上 9 点再次回落。一位同时拥有 Mac Studio 和 MacBook Pro 的成员确认了相同的行为，第三位还补充了一个有用的观察：如果你不运行系统监控工具，可能永远注意不到 CPU 负载，「但你一定会注意到电池掉得更快了」。

有几个细节值得分清，它们都是用户观察，并非 Apple 文档：

• 报告的时间是当地时间午夜。 帖子里有人说负载在早上 9 点结束。另一篇分析文章把卡住的时间戳描述为发帖者所在时区的「今天 00:00:00」。两者都不是 Apple 文档，都属于用户观察。
• 这并非最终版才出现的新问题。 帖子楼主指出，早期测试版中就有人见过，6 月 24 日的一篇中文分析文章也描述了 macOS 27 开发者测试版上 appstoreagent 的 CPU 占用超过 100%。因此这是一个长期存在并随正式版发布的 bug，而不是正式版新引入的回归。

如果这与你的 Mac 相符，请继续阅读。如果你的症状是白天发热，或者升级后持续数天发热而不仅仅是夜里，请直接跳到「其他原因」一节，因为同样的修复对你没有帮助。

dasd 与 appstoreagent 究竟是什么

在运行网上陌生人给的命令之前，最好先弄清楚你要动的是什么。

appstoreagent：App Store 的后台助手

appstoreagent 是属于 App Store 机制的每用户后台代理。它负责检查 App 更新、处理自动下载、验证许可并保持 App Store 状态同步。它平时不可见，CPU 占用通常接近 0%。它还有一项与本文相关的工作，即处理 Apple Arcade 的记账，这也是为什么与 Arcade 相关的偏好设置出现在它的域（com.apple.appstored）中。

dasd：Duet 活动调度器

dasd 是 Duet Activity Scheduler 守护进程，简称 DAS，是 Mac 上最重要的后台进程之一。The Eclectic Light Company 的 Howard Oakley 撰写的文章是目前关于这一子系统最好的公开文档，他这样描述：DAS 维护一份已调度活动的列表，并频繁评估它们，以确定接下来应该运行哪一个。当某个活动的综合得分超过阈值时，DAS 就决定运行它，并通过 XPC（Apple 的轻量级进程间通信机制）通知集中式任务调度（Centralized Task Scheduling，简称 CTS）启动它。

时间机器备份、软件更新清理、安全扫描、同步以及数十项日常维护作业，都要经过这条流水线。在 2026 年 7 月的一篇分析中，Oakley 统计到在 macOS 26.5.2 上启动后的第一分钟左右，提交给 DAS 的互不相同的活动至少有 701 个，并指出如今 Apple 芯片 Mac 上效率核心所做的工作，很大程度上由 DAS 和 CTS 负责。换句话说，dasd 就是一个交换机。当它消耗大量 CPU 时，通常意味着有东西在不断给它派活，或者在反复给它派同样的活。

调度器如何决策：得分、条件和阈值

Oakley 的文章列出了 DAS 计入得分的各项因素，包括电池电量、是否连接电源、能耗预算、CPU 占用、内存压力、热状态、网络质量、Mac 是否处于 Power Nap 状态，以及用户是否正在使用某个 App。各个活动还带有自己的条件，例如首次时间机器备份的条件是「启动后 300 秒内不运行」，DAS 会记录它的决策。他展示了形如「Decision: Can Proceed」和「Decision: Must Not Proceed」的日志条目，并附有得分和阈值。

这一设计的两个特性与我们的 bug 有关：

1. DAS 既按条件也按截止时间运行任务。 活动可以被标记为在某个特定时间到期。如果已经过期且条件满足，它就会运行。
2. 活动通过其所有者重新注册自己。 活动运行后，拥有它的进程（这里是 appstoreagent）会告诉调度器它下一次想在何时运行。日期一旦错误，问题就出在这里。

日志中的活动标识符形如 0:com.apple.softwareupdated.logs-cleanup:A2BBC8：依次是用户 ID、活动名称，以及 DAS 分配的一小段十六进制后缀。需要了解的子系统名称是：DAS 为 com.apple.duetactivityscheduler，CTS 为 com.apple.xpc.activity。你很快就会用到第一个。

报告的原因：一个永远不向前推进的截止时间

好几个人独立追踪到了同一个地方。最详细的公开分析是 nix-config 仓库中的 issue 82，它注明了 MacRumors 回复中所链接博客文章的中国开发者。其说法概括如下：

• 涉及的任务是 com.apple.appstored.ArcadeResetPO，该分析将其描述为 Apple Arcade 开发者分成重置任务。
• 任务运行后，com.apple.appstored 域中的偏好设置 ArcadePayoutResetDate 本应推进到下一个周期。但它却被锁定在过去的某个时间戳上。
• 因此 dasd 认为该任务已过期并立即运行它。appstoreagent 又用同样的过期时间重新注册它。这个循环大约每秒重复 70 到 100 次。
• 结果是一个核心被占满、统一日志大量写入、发热和电池耗电。

phobox360 脚本仓库由一位自称独立发现该 bug 的 MacRumors 成员编写，描述了相同的机制：一个名为 ArcadeResetPO 的 Apple Arcade 后台任务反复把自己调度到过去。这是两个人各自得出了同样的结论，比单一的个例更有分量，但仍然不是 Apple 的声明。

另有一篇更早的6 月报告描述了测试版时期的变体。它归咎于 Arcade 代码中的数据库错误（SQLite 表缺少一列，以及一条关于更新已在运行的任务的日志）和紧密循环的网络接口查询。它的主要价值在于证明这个问题早于正式版。它给出的补救办法是用 kill -STOP 冻结进程，冻结期间会停用 App Store 更新，这并不是现在大家推荐的做法。

如何确认这是你的问题

请按顺序操作。本节中没有任何步骤会更改设置。理想情况下，请在 Mac 出现异常时执行前两步，也就是午夜过后不久，或者早上起来还没做任何事情之前。

第 1 步：查看活动监视器

从「应用程序」>「实用工具」中打开活动监视器，点按「CPU」标签，并按「% CPU」列排序。你要找的是 dasd 和 appstoreagent 都排在靠前位置且持续占用 CPU，最好累计 CPU 时间也很大。据报告，在有此 bug 的 Mac 上会占满一个核心，因此在多核机器上单个进程接近 100% 就是典型特征。dasd 以 root 身份运行，所以如果你只看到自己的进程，请设置「显示」>「所有进程」。

如果 Mac 整晚处于空闲状态，即使峰值已过，appstoreagent 旁边巨大的 CPU 时间也是强烈的线索，因为该列是累计的。6 月的那篇分析展示了一行 top 输出，其中 appstoreagent 为 126.7%，运行时间超过 284 分钟。

第 2 步：在终端中用 top 确认

活动监视器足够用，但终端能给你可以直接贴到论坛帖子里的文本。top 打印的第一次采样是自开机以来的平均值，所以请让它采样两次，读取第二次的结果：

top -l 2 -n 10 -o cpu -stats pid,command,cpu,time

-o cpu 按 CPU 排序，-n 10 把列表限制为十个进程，-l 2 采样两次，-stats 选择要显示的列。请阅读第二个数据块。如果 Mac 在其他方面处于空闲时，dasd 和 appstoreagent 都排在前几位，且都不接近零，就与该 bug 相符。更简短的替代方法是 ps -axo pid,pcpu,time,comm -r | head，它按当前占用率列出最耗 CPU 的进程。

第 3 步：读取 Arcade 日期

这是决定性的测试，因为它检查的是报告的原因，而不是症状。phobox360 项目的讨论给出了一种与语言环境无关的读取方式。该键位于 com.apple.appstored 域，用 plutil 读取时，值以 ISO 8601 格式返回：

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
defaults read com.apple.appstored ArcadePayoutResetDate
date -u +"%Y-%m-%dT%H:%M:%SZ"

第一条命令以 2026-09-26T22:00:00Z 的格式打印已存储的日期。第二条通过你的语言环境设置打印同样的内容，更易阅读，但正如脚本作者发现的，在 12 小时制的语言环境下可能呈现不同，所以如果你打算用程序比较，请使用第一条。第三条以同样的格式打印当前时间，方便你目视对比。

如何解读：

• 存储的日期在过去（早于当前 UTC 时间），同时 dasd 和 appstoreagent 很忙：与报告的 bug 相符。
• 存储的日期在未来，且进程很安静：你遇到的不是这个 bug。
• **存储的日期在未来，但进程仍然很忙：**是别的原因，或者该循环有尚未公开描述的成因。请使用下方的进程对照表。
• **该键不存在：**说明 App 尚未创建它，这既不能证明也不能否定。从未启动过 App Store 或 Apple Arcade 的 Mac 可能没有这个键。

在更改任何内容之前先保存这个输出。它是原始值的记录。

第 4 步：用精确的谓词查看统一日志

「每秒 70 到 100 次」的说法可以在日志中核实。macOS 的 log 命令接受 NSPredicate 过滤器，简写形式 process == "name" 在 log 手册页中有说明。要以紧凑的单行格式查看 dasd 最近几分钟的日志：

log show --predicate 'process == "dasd"' --last 5m --style compact | head -50

要统计它在一分钟内写了多少行，这是一个粗略的速率：

log show --predicate 'process == "dasd"' --last 1m --style compact | wc -l

在正常的 Mac 上，这个数字很小。如果该 bug 处于活动状态，就会出现大量日志；报告称该循环会造成大量统一日志写入。你也可以按调度器的子系统过滤，或者直接搜索任务名称：

log show --predicate 'subsystem == "com.apple.duetactivityscheduler"' --last 2m --style compact | head -50
log show --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --last 2m --style compact | head -50

按任务名称过滤最为精确。如果 ArcadeResetPO 在一分钟内出现几十次，就证实了所报告的 bug。若想实时观察而不是事后查看，请用相同的谓词配合 log stream：

log stream --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --style compact

按 Control-C 停止。有两点提醒。第一，在有此 bug 的 Mac 上，不要用宽松的谓词对数小时的日志运行 log show，因为日志可能极其庞大，命令会慢如蜗牛。请保持较短的时间窗口。第二，我们在这里给出的是有文档依据的语法，而不是你的日志中实际内容的记录。不同版本的消息措辞可能不同，所以如果第一个过滤器没有结果，请先试试进程过滤器，再断定该 bug 不存在。

第 5 步：检查是什么让 Mac 保持唤醒

如果循环正在运行，你还想知道 Mac 是一直醒着，还是被它唤醒的。有两条 pmset 读取命令可以帮忙。

pmset -g assertions
pmset -g log | grep -E "DarkWake|Wake "

第一条显示当前的电源断言，也就是目前正在阻止睡眠的东西，比如后台任务或让显示器保持唤醒的进程。第二条打印电源日志中的唤醒历史；每条唤醒记录都有「due to」原因，而 DarkWake 是部分唤醒，即 Mac 屏幕保持黑屏、同时在后台工作。手册页把 -g log 描述为睡眠、唤醒及其他电源管理事件的历史记录，供管理员和调试使用。整晚出现一连串 DarkWake，每次都由网络或维护原因触发，说明问题出在调度路径上。若是一整段不间断的完整唤醒，则说明有东西让 Mac 一直醒着。我们的 Mac 睡眠问题指南详细讲解了如何阅读这些日志行。

判断表：哪个进程对应哪种原因

这个 bug 之所以让人困惑，是因为另外六七种互不相关的作业也会在夜间表现为后台 CPU 占用。下表把你在活动监视器中看到的现象对应到最可能的解释。它是根据 Apple 文档和本文引用的来源整理的诊断辅助，并不保证一定准确。

CPU 占用靠前的进程	最可能的原因	正常还是有问题？	首先检查
dasd 和 appstoreagent 都很忙，常从午夜开始	所报告的 Arcade 日期循环	有问题（已报告的 bug）	第 3 步：ArcadePayoutResetDate 是否在过去？
mds、mds_stores、mdworker_shared	Spotlight 索引	升级后的数小时到几天内属正常；若一直无法结束则有问题	我们的 Spotlight 重建索引指南
photoanalysisd、mediaanalysisd	照片正在扫描资料库（人物、场景、物体）	升级后或大量导入后属正常，尤其是接通电源时	打开照片，查看资料库中的分析状态
backupd、backupd-helper、diskarbitrationd	时间机器备份	每小时一次属正常；若始终无法完成则有问题	系统设置 > 通用 > 时间机器，以及我们的时间机器故障排查指南
bird、cloudd、fileproviderd	iCloud 云盘或其他文件提供程序正在同步	大量同步期间属正常；若陷入循环则有问题	检查 iCloud 云盘状态以及近期更改的大小
powerd、kernel_task 在空闲时占用高	热管理或电源断言	视情况而定；通常是症状而非原因	第 5 步和断言列表
仅 dasd，内存增长到数 GB	另一个 dasd 内存问题，一家第三方博客根据用户反馈报告于 macOS 27 测试版	有问题，但属于另一个问题，日期修复不适用	活动监视器的「内存」标签
contactsd、peopled	通讯录小组件和通话记录数据库	Tahoe 时期已知的问题	我们的 peopled 与 contactsd 指南
某个第三方 App 或其辅助进程	该 App 本身	该 App 的问题	退出它；检查是否有更新

从这张表可以得出两条经验法则。第一，配对很重要：单独的 dasd 是一个正在派发大量工作的调度器，CPU 往往是被它所派发的进程消耗掉的。dasd 加上 appstoreagent 在固定时间同时出现，才是报告中的模式。第二，时间也很重要：索引和照片分析在升级后最为繁重并逐渐消退，而与午夜相关的循环应该每晚都会重现。

社区解决方法，逐行解读

MacRumors 成员和各篇分析文章最终趋同的修复方法，就是一次偏好设置更改。下面是帖子中发布的形式，并附上帖子里没有给你的解释。

更改任何内容之前：保存原始值

先备份现有的内容，以便日后恢复。这两条命令都不会修改任何东西。

defaults read com.apple.appstored ArcadePayoutResetDate > ~/Desktop/arcade-date-before.txt
defaults export com.apple.appstored ~/Desktop/appstored-before.plist

第一条把当前日期写入一个文本文件。第二条把整个 com.apple.appstored 偏好设置域导出为桌面上的属性列表。如果第一条命令打印「does not exist」，说明该键不存在，你可以跳过第一行。

命令

按 MacRumors 上的发布形式，并被 nix-config issue 重复引用，七天版本如下：

defaults write com.apple.appstored ArcadePayoutResetDate -date "$(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ")" && killall appstoreagent

逐部分拆解：

• defaults write com.apple.appstored ArcadePayoutResetDate -date "..." 向 App Store 代理的偏好设置中的 ArcadePayoutResetDate 键写入一个日期值。-date 标志告诉 defaults 该值是日期而不是字符串。
• $(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ") 是由 shell 计算该日期。date -v+7d 是 BSD date（macOS 自带的那个），把当前时间向后调整七天，-u 使用 UTC，格式字符串生成以 Z 结尾的 ISO 8601 时间戳。Homebrew coreutils 提供的 GNU date 使用不同的标志，所以如果你已在路径中替换了系统的 date，请以 /bin/date 运行。
• && 仅在写入成功时才运行后面的部分。
• killall appstoreagent 终止正在运行的 appstoreagent，让它重新启动并读取新的偏好设置。系统会按需再次启动它，所以这不是永久关闭。如果 App Store 正在下载或更新，这会将其打断，所以请尽量在没有更新进行时操作。

请以普通用户身份运行，不要使用 sudo。该偏好设置属于你的账户，phobox360 项目也明确告诉用户不要使用 sudo。以 root 身份写入偏好设置会创建一个代理可能读不到的文件。

你应该看到的现象：重启后几秒内，dasd 和 appstoreagent 在活动监视器中应降到接近零。最早记录该命令的那篇分析说修复立即生效。这是一位用户报告的结果，而不是我们能向你的 Mac 保证的。

这做了什么、没做什么

• 它只更改一个日期。 没有删除任何内容，没有触碰任何系统文件，没有禁用任何保护。com.apple.appstored 是普通的每用户偏好设置域。
• 它并没有修复导致日期过期的 bug。 它只是把截止时间挪到够不着的地方，让调度器不再把该任务视为过期。报告者把它描述为在 Apple 发布真正的修复之前的权宜之计。
• 目前不知道它会影响你的 Apple Arcade 订阅或游戏。 所涉及的任务被描述为开发者分成重置。但还没有人发布过把日期推到很远之后 Arcade 记账会发生什么的测试。脚本作者对更激进的 2035 选项也是这么说的。如果你重度使用 Arcade，请优先选择较短的七天窗口。

选择日期：七天，还是数年

nix-config 的分析使用 2099-01-01T00:00:00Z，等于把任务无限期搁置：

defaults write com.apple.appstored ArcadePayoutResetDate -date "2099-01-01T00:00:00Z"
killall appstoreagent

这样就不必每周重复修复，据报道能长期搁置该任务且「不会破坏 App Store 功能」，但这一说法出自报告者，并非 Apple 确认的内容。phobox360 脚本的可选持久模式使用 2035 年，并附有明确警告：其对 Arcade 记账的影响尚未得到独立验证。我们的建议是判断而非有文档依据的事实：先从七天开始。如果奏效，你就以较低风险确认了诊断正确，之后可以再决定是否走得更远。

如何撤销

回退有两种方式，最好在需要之前就了解这两种方式。

**恢复保存的值。**如果你保存了原始日期，而且它是有效的过去日期，把它写回就能回到之前的状态，当然，那正是存在循环的状态。实际上你只会为了测试，或者在提交给 Apple 的 bug 报告中提供一份干净的状态才这样做。请使用文本文件中的 ISO 字符串：

defaults write com.apple.appstored ArcadePayoutResetDate -date "2026-09-26T22:00:00Z"
killall appstoreagent

请把示例日期替换成你自己保存的值。

**删除该键。**这会移除你的覆盖值，让代理在没有存储值的情况下启动：

defaults delete com.apple.appstored ArcadePayoutResetDate
killall appstoreagent

删除键是 defaults 把某项设置恢复为默认值的标准做法。在 macOS 27 上，键缺失时 App Store 代理会怎么做并没有文档说明，它可能重新创建一个有效的新日期，也可能是有问题的那个。如果删除该键后循环又回来了，请再次应用这个解决方法。

脚本方案，以及该信任到什么程度

dasd-arcade-loop-fix 仓库把同样的更改封装成脚本，带有试运行、确认提示、自动备份原始值和回滚命令。写作本文时，它是一个星标和复刻都几乎为零的小项目，尚未被广泛审查。合理的做法是在运行之前先读一遍脚本，或者干脆用上面的单行命令，它做的是同一件事，而且完整地呈现在你眼前。如果你确实使用脚本，其文档中的标志有试运行、默认的一周延期和 --rollback。一个拉取请求修复了 12 小时制语言环境下因 defaults read 打印日期的方式而导致的中止，这也提醒我们：解析偏好设置输出的 shell 脚本是脆弱的。

不要这样做

• **不要杀死 dasd。**它归 root 所有，launchd 会立刻重启它，而你无法通过杀死调度器来修复它。这也解决不了任务过期的原因。
• **不要把 kill -STOP 或卸载 appstoreagent 当作长期措施。**6 月的那篇分析使用 kill -STOP，是因为在测试版上别的办法都不管用。它会挂起进程，所以 App Store 更新、下载和许可检查都会停止，直到你用 kill -CONT 恢复它。
• **不要禁用系统完整性保护，也不要编辑 /System 文件。**任何报告中的做法都不需要这样。
• **不要仅仅关闭自动更新就说已经修好了。**一位 MacRumors 回复者建议这样做，它也许能减少代理被唤醒的频率，但并没有解决所报告的原因：该任务是 Arcade 分成重置，而不是检查更新。这样做还会让你失去 App Store 应用的自动安全更新。如果为了测试而关闭，请记得重新打开。

为什么会复发，以及该怎么办

如果你使用了七天命令，你写入的日期现在是一个真实有效的日期，在那一天过去之前，调度器会相安无事。一旦过了这一天，过期日期的情况又有可能出现。报告称循环可能在大约一周后复发。其机制正如从 bug 描述中所能预料的：修复只是移动了截止时间，而未能正确推进它的那个 bug 依然存在。

你有两个选择。

1. **每周重复该命令。**在日历里设一个提醒。这样成本很低，也能让你的 Arcade 状态接近正常。
2. **使用一个晚得多的日期。**2099 这种形式免去了这项杂务。代价是前面已经说过的：Arcade 记账处于测试更少的领域。

macOS 27.0.1 修复了吗？

我们不知道，我们宁愿这样告诉你，也不愿去猜。

我们能核实的是：Apple 于 9 月 28 日发布了 macOS 27.0.1。据 The Eclectic Light Company 的报道，新的版本号为 26A434，该更新「似乎修复了未具体说明的 bug，以及一个影响 Platform SingleSignOn 的问题」，且没有公开的安全发行说明。那篇文章没有提到 CPU、电池、App Store 或 Apple Arcade。

帖子里显示的是：27.0.1 发布后，楼主写道「不知道现在这个问题在 macOS 27.0.1 里修好了没有」。随后的回复谈的是另一个 bug，即文件扩展的本地网络权限问题，并确认那个问题没有修复。帖子中没有人报告 Arcade 循环修复前后的对比结果。

所以，诚实的立场是：无论正反两方面，都未经证实。另外请注意，含糊的发行说明很常见，所以修复可能已经存在，只是没有被列出来。

要在自己的 Mac 上查明，并产生有用的证据，可以这样做：

1. 更新到 27.0.1（系统设置 > 通用 > 软件更新）。
2. 在应用任何解决方法之前，先运行第 3 步读取 ArcadePayoutResetDate。
3. 如果你已经应用了解决方法，请等到你设置的日期过去，或者按上文所述删除该键并重启，然后观察跨午夜的情况。
4. 第二天早上查看 top 或活动监视器，并用任务名称谓词读取日志。
5. 把你的发现发到 MacRumors 的帖子里。阅读该帖子的人，正是需要这个答案的人。

需要排除的其他夜间发热和耗电原因

即使你的 dasd 确有问题，它也可能不是唯一的原因。升级会触发一大堆补做的作业，同时存在不止一个问题是很常见的。在断定 Arcade 循环就是全部原因之前，请把这些都排查一遍。

升级后的 Spotlight 与 Siri 索引

大版本升级后，macOS 会重建部分搜索索引，表现为 mds、mds_stores 和 mdworker_shared。Apple 自己关于意外唤醒的指南提到，如果 Spotlight 正在为你的磁盘建立索引，Mac 就不会进入睡眠，而无法睡眠的 Mac 会发热并在夜间耗尽电量。索引是有限的：它会高强度运行数小时，在大容量硬盘上有时要一两天，然后就会平息。Arcade 循环则不会平息。我们的 macOS 27 后 Spotlight 重建索引指南介绍了如何区分「仍在工作」和「卡住了」，而 macOS 26.6 的早期报告则展示了 Siri 索引的同样模式。

照片分析

photoanalysisd 和 mediaanalysisd 会扫描你的照片资料库，识别人物、场景和物体。它们在升级或导入之后最为繁重，而且会结束；它们没有固定的开始时刻。让 Mac 整晚接通电源，看看负载是否在几个晚上之内逐渐消退。

时间机器

时间机器备份通过同一个调度器运行。Oakley 的文章展示了 DAS 在启动后的最初几秒拒绝一次备份，因为该活动要求等待五分钟，这就是条件在起作用的一个例子。升级后的首次备份，或者备份到较慢的网络目标，可能运行数小时并使 Mac 发热。如果繁忙的进程是 backupd，请参阅时间机器故障排查指南，而 Oakley 的关于备份调度与派发的文章解释了备份为什么会在奇怪的时刻启动。

Power Nap 与网络唤醒

Apple 的睡眠与唤醒设置页面说明，Power Nap 让 Mac 在睡眠期间自行更新，而「为网络访问唤醒」让它短暂唤醒，以便其他用户访问共享服务。在笔记本上，这两项都位于系统设置 > 电池 > 选项。Apple 的意外唤醒页面在其建议中列出了停用网络唤醒和关闭共享服务。pmset 手册页说明 womp 是终端中与「为网络访问唤醒」等效的设置，而 powernap 适用于受支持的机器。Power Nap 的可用性因机型而异，所以看不到它也不必意外。

要查看当前的值而不更改：

pmset -g | grep -E "powernap|womp"

如果你的 pmset -g log 显示夜间有规律的 DarkWake，把两者都关掉是一个合理的实验。它不会修复 Arcade 循环，因为那发生在 Mac 处于唤醒或为维护而唤醒的时候，但它能为你的诊断去除干扰。一次只改一项，这样你才能知道是什么起了作用。

常见问题排查

执行命令后进程仍然很忙

症状：你运行了 defaults write 和 killall，但 dasd 和 appstoreagent 仍然排在活动监视器的前列。

原因：有几种可能。killall 可能没有匹配到，所以旧进程仍在运行，缓存着旧日期。写入可能悄悄失败了，例如域名拼写错误。也可能你看到的根本是另一个原因。

解决方法：

1. 用 plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist 读回该值，确认它在未来。
2. 再次运行 killall appstoreagent，然后在活动监视器中检查该进程是否以新的 PID 重新启动。
3. 用任务名称的日志谓词重新查看一分钟。如果 ArcadeResetPO 不再出现但 CPU 仍然很高，则原因是别的，上方的进程对照表就是你的下一站。

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
pgrep -l appstoreagent

如果仍然无效：重启一次 Mac。重启会清除缓存的偏好设置和任何卡住的调度器状态。如果重启后日期仍然有效而负载依然存在，请把它当作另一个 bug，并在求助之前收集第 2 步和第 4 步的输出。

一周后循环又回来了

症状：安静了一周，然后午夜飙升再次出现。

原因：你设置的七天日期已经过去，而底层 bug 仍然存在。

解决方法：再次运行该命令，或者按前文所述选择更晚的日期。如果你不想重复操作，请在知情的前提下选择更长的窗口，并记住它对 Arcade 记账的影响没有文档说明。

Mac 夜里仍然耗电，但进程看起来很安静

症状：dasd 和 appstoreagent 为零，电池仍然下降。

原因：睡眠期间的发热和耗电通常来自唤醒和断言，而不是 CPU。

解决方法：读取夜间时段的 pmset -g log，看看 Mac 唤醒了多少次、为什么唤醒。检查 pmset -g assertions，看有没有东西在阻止睡眠。我们的 Mac 睡眠问题指南和 macOS Tahoe 电池耗电修复指南介绍了常见的罪魁祸首，高级电池诊断指南则更深入地讲解了如何读取电池数据。

常见问答

为什么 macOS 27 上 dasd 和 appstoreagent 占用这么多 CPU？

MacRumors 成员的反馈和独立分析文章称，一个 Apple Arcade 任务 ArcadeResetPO 让存储的日期停留在过去，所以调度器不停地重新运行它，可能每秒 70 到 100 次。Apple 尚未确认。表现为一个核心被占满，常从午夜开始，伴随发热和更快的电池消耗。

运行 ArcadePayoutResetDate 的 defaults write 命令安全吗？

它只更改一项每用户偏好设置，不触碰系统文件，并且可以通过删除该键或恢复保存的值来撤销。这是社区的解决方法，而不是 Apple 的指导意见，其对 Arcade 记账的长期影响没有文档说明。请先保存原始值，并优先选择较短的窗口。

macOS 27.0.1 修复了 dasd 和 appstoreagent 的循环吗？

我们无法证实。Apple 的 27.0.1 更新（版本号 26A434）据报道修复了未具体说明的 bug 和一个 Platform SSO 问题，没有提到这一项。MacRumors 上唯一询问此事的帖子得到的回复谈的是另一个 bug。请在自己的 Mac 上跨午夜读取该日期来测试。

我怎么知道是这个 bug，而不是 Spotlight 或照片？

用 plutil 读取存储的日期，并与当前 UTC 时间比较。如果它在过去，同时 dasd 和 appstoreagent 很忙，且日志显示 ArcadeResetPO 任务在重复出现，那就是这个 bug。Spotlight 表现为 mds 进程，照片表现为 photoanalysisd，二者都没有固定的午夜开始时间。

为什么一周后问题又回来了？

该解决方法把重置日期推后一周。那个日期一过，未能推进它的底层 bug 可能再次发作，于是循环回来。报告者描述它在大约一周后复发。你可以每周重复该命令，或者选择更晚的日期，但要接受较长的日期测试更少。

关闭 App Store 自动更新能阻止它吗？

一位 MacRumors 回复者说这样可以让这些进程安静下来，但它并没有解决所报告的原因，也就是 Arcade 分成任务而非更新检查。这还意味着你不再自动接收 App Store 应用的更新。请把它当作可以测试的取舍，而不是修复，如果没有帮助，请重新打开更新。

我能直接杀死 dasd 或 appstoreagent 吗？

杀死 appstoreagent 能让峰值短暂停止，但系统会按需重新启动它，而过期日期仍然存在，所以循环会继续。dasd 是归 root 所有的调度器，launchd 会立即重启它。用 kill -STOP 冻结 appstoreagent 有效，但会让 App Store 更新和许可检查停止，直到你恢复它。

这个修复会影响我的 Apple Arcade 游戏或订阅吗？

公开报告中没有任何内容表明会。该任务被描述为开发者分成重置，而这个解决方法只更改一个日期。但没有人发布过把它推到多年之后的测试，脚本作者也明确表示其对 Arcade 记账的影响尚未确立。如果你玩 Arcade，请使用较短的窗口。

结论

在越来越多的报告中，macOS 27 上 Mac 夜里发烫又耗尽电量的背后，是一个调度器循环：dasd 派发任务，appstoreagent 重新注册一个日期永远不向前推进的 Apple Arcade 任务。在不更改任何内容的前提下确认它成本很低：读取存储的日期，与 UTC 比较，并在日志中查找任务名称。如果日期在过去，据报道社区的单行解决方法能立即停止循环，而且很容易撤销。

请保持务实的预期。这只是权宜之计，除非你接受更长的日期，否则需要重复执行；Apple 尚未承认该问题，我们也无法告诉你 27.0.1 或任何后续更新是否修复了它。如果日期检查结果正常，不要硬套这个诊断；请按照上面的判断表，逐一排查 Spotlight、照片、时间机器、iCloud 和唤醒设置。

想进一步深入的话，我们的 Spotlight 重建索引指南介绍了升级后 Mac 发热最常见的正当原因，Mac 睡眠问题指南介绍了唤醒和断言问题。如果罪魁祸首是别的进程，peopled 与 contactsd 指南也许能对上。而且，如果你查明了 27.0.1 在你的 Mac 上是否带来了变化，请告诉 MacRumors 帖子里的人。

有问题或经验想分享？欢迎在下方评论区告诉我们。

相关阅读：macOS 27 后 Spotlight 重建索引、macOS 26.6 后 Mac 发热并耗电、macOS Tahoe 电池耗电完整修复指南、macOS 27 Golden Gate 发布日更新指南