macOS 27 睡眠掉电快？Mac 合盖一晚上掉电，用 pmset 查出是谁在唤醒它

晚上合上盖子时电量还是 100%，早上一摸 Mac 是烫的，电量只剩 40%、20%，甚至已经关机。自 macOS 27 Golden Gate 于 9 月 14 日发布以来，这样的故事在 Apple 支持论坛里一再出现：MacBook 本该在睡眠或闲置状态下，电量却掉得吓人，而且还发烫。常见的建议是「等 Spotlight 索引完」「关掉一些 App」，但对于升级三周后仍然一夜掉三分之一电量的人来说毫无用处。本指南换一种思路：不堆砌泛泛的小技巧，而是教你用 macOS 内置的日志工具，实际测量你的 Mac 整夜到底做了什么，怎么读输出，以及每种模式该怎么处理。文中还涉及用户报告的两个具体的失控进程 replicatord 和 agentstored，说明目前已知与未知的信息，以及该向 Apple 提交什么才能让反馈真正有用。

核心要点

• 这些反馈是真实的，但 Apple 尚未承认。 截至 10 月 14 日，Apple 支持社区的主帖有 73 个「Me too」点击和 16 条回复。没有 Apple 员工回应，Apple 对 27.0.1 也只写了「错误修复」。
• 并非每台 Mac 都受影响。 一位资深论坛用户称，他的 16 英寸 M4 Pro MacBook Pro 剩 50% 电量时仍可使用约 10 小时。请测量你自己的 Mac。
• 先测量，再动手改。 pmset -g log 会记录每一次睡眠、唤醒和 DarkWake 及其原因，pmset -g assertions 则显示此刻是谁在阻止 Mac 休眠。
• 唤醒原因是线索，不是结论。 维护性唤醒属于正常现象。每 15 分钟一次的 DarkWake，或持续数分钟的 DarkWake，才是值得追查的模式。
• 有两个进程案例。 有用户通过重命名数据库文件，修复了 replicatord 占满 100% CPU 的问题。agentstored 目前没有已知的修复方法。
• 别用清理软件、别改 SIP、别反复重置。 如果仔细测量后 Mac 仍然异常，就带上 sysdiagnose 提交反馈。

用户实际报告了什么

最详细的报告是 Apple 支持社区的帖子 「Severe Battery Drain and overheating on MacBook Pro M5 after upgrading to macOS 27 Golden Gate」，发帖时间为 9 月 22 日。我们在 10 月 14 日阅读时，它有 73 个「Me too」点击，分两页共 16 条回复。楼主描述自己的 MacBook Pro（M5 Pro，2026 年 5 月购买）升级前一夜几乎不掉电；升级后，拔掉电源不使用，「第二天早上电池可能会被完全耗尽」，闲置时机身也发烫。在一次测试中，Mac 本该处于睡眠状态，电量却在约 16 小时内从大约 100% 掉到 1%。

帖子里的其他报告，均为用户自述，我们无法核实：

• 一位 MacBook Air M5 用户称，续航从十多个小时降到了四五个小时。
• 一位 16 英寸 M4 Pro 用户称，原本能用两天，现在只能用六小时；不过有志愿者指出，附带的截图里显示屏是亮着的，说明 Mac 并没有睡眠。
• 一位 M3 MacBook Air 用户在 27.0.1 上两次遇到「完全没在用却把电耗光了」。
• 一位运行 27.2 版本的 MacBook Air M5 用户称，每次更新都「变得更糟」。
• 一位 MacBook Pro M5 用户在 10 月 8 日发帖称，Mac 大约每 15 分钟就会进入一次 DarkWake，日志里归因于 wifibt 和 SMC.OutboxNotEmpty，即使关闭了 Wi-Fi 和蓝牙也一样。

有两点需要说明。第一，楼主在 9 月 27 日写道，卸载了那些「不适用于此 macOS 版本」的应用后，Mac 恢复了正常，但没有说明具体是哪些：这只是个案，不是通用的解决办法。第二，Apple 尚未承认 macOS 27 存在电池问题；帖子里有志愿者提到，Apple 并不参与这个论坛。我们找到的唯一官方说明，是 Apple 安全更新页面上对 27.0.1（构建号 26A434，9 月 28 日）的描述，其中没有提到电池续航。

大版本升级后什么算正常（以及持续多久）

每次大版本升级都会触发后台工作：Spotlight 重建索引，「照片」重新分析资料库，iCloud 重新同步，而在支持 Apple Intelligence 的 Mac 上，设备端模型还可能需要下载。第一天发烫的 Mac，通常到第四天就没事了。

Apple 没有公布具体时长。 我们查遍了 Apple 的支持页面，没有找到。第三方指南给出了 72 小时之类的数字，但没有一个引用 Apple 的说法。时长取决于资料库的大小，也取决于 Mac 有多少时间处于闲置并接通电源的状态。

迹象	更可能是正常的索引	更可能是真正的问题
升级后的时间	一到三天	一周或更久，就像主帖里那样
发热的场景	Mac 开着盖、插着电，你人走开了	Mac 合着盖或装在包里，靠电池供电
进程	mds_stores、photoanalysisd、cloudd 先忙一阵，然后平静下来	某个进程连续数小时占满一个核心的 100%
几天内的趋势	每晚都比前一晚好一点	持平或越来越差

各个具体原因请参阅：macOS 27 之后的 Spotlight 重新索引、升级后那 30 GB 去哪了（主帖里有志愿者提到一个案例：只剩 8 GB 可用空间的 Mac 出现了快速掉电）以及 Apple Intelligence 卡在「正在准备」。另有一位社区用户称，macOS 27 中无法关闭 Apple Intelligence；我们无法确认这一点，因此不基于它给出任何建议。

第 0 步：先确认这确实是睡眠问题

1. 做一次对照测试。 充满到 100%，拔掉电源，合上盖子，记下时间，然后放置一段固定的时间，比如八小时。打开时写下电量百分比。第二晚再重复一次。
2. 保持你平时的使用环境。 蓝牙鼠标和扩展坞保持平时的状态，这样测试才能复现你真实的过夜情况。
3. 确认 Mac 真的睡着了。 帖子里有志愿者指出，合上盖子「未必会让笔记本进入睡眠」，因为任何持有睡眠 assertion 的程序都会让它保持清醒。一台装在包里醒着的 Mac 会掉电很快并且发热。

测试结果就是一个标签：「整夜醒着」「断断续续醒来」，或者「睡着了但仍在掉电」。后面的步骤会告诉你该怎么区分。

测量工具箱：四条命令加一个 App

下面所有命令都记录在 macOS 自带的手册页中，你可以用 man pmset、man top 等查看。这里的语法与 macOS 27.0.1 的手册页一致。对于 Apple 没有文档说明的日志格式，我们会明确指出：手册对 pmset -g log 输出的描述只有一句：「睡眠、唤醒及其他电源管理事件的历史记录。该日志供管理员和调试使用。」下文对各行内容的解读是基于经验的推断，并非 Apple 文档。

先提醒一个 zsh 的坑：在 macOS 默认的 shell 中，log 是 shell 内建命令，所以 log show 会报「too many arguments」。请始终像示例那样写完整路径 /usr/bin/log。

命令 1：pmset -g stats，一行概览

pmset -g stats

手册把 -g stats 描述为打印「系统自启动以来经历的睡眠和唤醒次数」。输出共三行：Sleep Count、Dark Wake Count 和 User Wake Count。这是你的第一道快速检查。如果你一天前重启过，却看到 Dark Wake Count 有几百次，说明 Mac 在频繁地自己醒来。主帖里的那位用户看到的是「自启动以来 225 次睡眠/唤醒，其中一个睡眠周期出现了 7 次 Dark Wake」。

次数多并不一定是坏事：DarkWake 是一种部分唤醒，显示屏保持关闭，Mac 在后台工作几秒钟，Mac 日常会为维护而这样做。帖子里有志愿者表示，大多数 DarkWake 几乎不耗电，持续不到一分钟，而他自己的 Mac 上出现过一次 15 分钟的 DarkWake，这并不寻常。这些只是个人观察，但与关键的一点吻合：次数告诉你要不要去查；持续时间和原因告诉你查到的是什么。

命令 2：pmset -g log，睡眠与唤醒历史

pmset -g log | awk '$4=="Sleep"||$4=="Wake"||$4=="DarkWake"' | tail -60

这份日志可能有几万行，其中大多数是电源 assertion。上面的过滤只保留 Sleep、Wake 和 DarkWake 条目。论坛里有志愿者贴过一个更短的、带双空格的 grep：grep -E 'Sleep |Wake '，它能用是因为类型列做了空格填充，但它也会匹配到少量 assertion 汇总行，所以 awk 版本更干净。保留下来的每一行都以日期、时间和时区开头，接着是事件类型，然后是详细信息。

下面是 macOS 27 上一段健康的过夜序列，内容为便于理解做了少量编辑：

09:00:41 Sleep      Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:100%) 31 secs
09:01:12 DarkWake   DarkWake from Deep Idle [CDNP] : due to smc.sysState.Wake(0x70070000) USB-C_plug SMC.OutboxNotEmpty Using BATT (Charge:100%) 0 secs
09:01:13 Sleep      Entering DarkWake state due to 'Notification Wake Back to Sleep':TCPKeepAlive=active Using AC (Charge:100%) 108 secs
09:03:01 Wake       DarkWake to FullWake from Deep Idle [CDNVA] : due to UserActivity Assertion Using AC (Charge:100%)

从左到右逐项读：

• 事件类型。 Sleep 表示 Mac 进入睡眠或回落到 DarkWake。DarkWake 是不亮屏的唤醒。Wake 是完整唤醒。Entering ... state due to 'Reason' 告诉你它为什么睡下去。
• 引号里的原因。 Maintenance Sleep、Sleep Service Back to Sleep 和 Notification Wake Back to Sleep 表示 Mac 结束了一次后台会话。Clamshell Sleep 是合上了盖子。Idle Sleep 和 Software Sleep 是定时器或 App 的请求。
• TCPKeepAlive=active。 Mac 在睡眠期间保持 TCP 连接，这是 tcpkeepalive 设为 1 时的标准行为。
• 「due to」之后的唤醒原因。 这是你最该关注的字符串。示例见本文后面的表格。
• Using BATT 或 Using AC，以及括号里的电量。 这是当时的供电来源和电池百分比。对比整晚的 Charge 值，就能得到一条掉电曲线，无需任何第三方工具。
• 末尾的秒数。 它似乎表示 Mac 在刚刚离开的那个状态里停留了多久，不过 Apple 没有文档说明。以 Sleep ... 31 secs 结尾的 DarkWake，说明醒了大约半分钟；以几百秒结尾的，则说明醒了好几分钟。

要把日志变成一条掉电曲线，只打印时间、事件类型和电量：

pmset -g log | awk '$4=="Sleep"||$4=="Wake"||$4=="DarkWake" {match($0,/Charge:[0-9]+%/); print $1,$2,$4,substr($0,RSTART,RLENGTH)}' | tail -80

按小时统计 DarkWake 次数，这样 15 分钟一次的节奏就一目了然：

pmset -g log | awk '$4=="DarkWake"{print $1, substr($2,1,2)":00"}' | sort | uniq -c | tail -24

在能正常睡眠的 Mac 上，每小时只会看到寥寥几次 DarkWake。主帖中 10 月 8 日的那份报告里，MacBook Pro M5 整夜乃至白天都大约每 15 分钟醒一次，在这里会表现为稳定的每小时四次，其中有些单次唤醒持续 20 秒以上。仅凭这一点还不足以下结论，但这个节奏值得给出解释。

命令 3：Wake Requests，谁请求了下一次唤醒

同一份日志还会记录计划中的唤醒请求，也就是 Mac 为自己安排的未来唤醒。它们长这样，已缩短：

pmset -g log | grep "Wake Requests" | tail -3

Wake Requests  [process=mDNSResponder request=Maintenance deltaSecs=7198 wakeAt=... info="upkeep wake"]
               [process=dasd request=SleepService deltaSecs=1016 wakeAt=... info="com.apple.dasd:501:..."]
               [process=powerd request=TCPKATurnOff deltaSecs=316236 wakeAt=...]

每个方括号是一条请求：发出请求的 process、request 类型、距现在多少秒（deltaSecs），以及一段自由文本的 info 字符串。这是系统能给你的、最接近「嫌疑人名单」的东西。其中的 dasd 条目是 Duet Activity Scheduler，它负责调度后台任务，并可以唤醒 Mac 来运行它们；较长的 info 字符串会指明具体任务。在主帖里，有用户列出了自己日志中出现的任务，包括 com.apple.intelligenceflow.toolbox.update.fastpass、屏幕使用时间历史清理和 PowerUIAgent 维护。这些是某个人的 Mac 上的名字，不能证明存在 bug。如果同一个不寻常的任务名在整晚的每次唤醒请求里都出现，那就是你的线索。关于调度器的运作机制，参阅我们的文章 dasd 和 appstoreagent 在夜间运行。

命令 4：pmset -g assertions，此刻是谁在阻止 Mac 休眠

pmset -g assertions

手册说它「显示电源 assertion 的摘要。Assertion 可能会阻止系统睡眠或显示器睡眠」。Assertion 是某个进程发出的请求：「我做这件事期间，请不要睡眠」。输出顶部是一张计数汇总表；下方的「Listed by owning process」会列出每个持有者。请重点关注这些：

Assertion	含义	非零值意味着什么
PreventUserIdleSystemSleep	有东西在阻止空闲睡眠	某个进程（视频、下载、caffeinate、远程访问工具）想让 Mac 保持清醒
PreventSystemSleep	更强：完全阻止睡眠	很少是好事；在某些硬件或音频工作流中比较常见
PreventUserIdleDisplaySleep / InternalPreventDisplaySleep	显示器被保持点亮，或有待处理的超时	如果你正在使用 Mac，则属正常
BackgroundTask	有后台任务在运行	通常是暂时的；持续不为零则说明有任务卡住
NetworkClientActive	网络活动正在让 Mac 保持清醒	有传输或同步正在进行
UserIsActive	Mac 认为你正在使用它	常常是蓝牙鼠标或键盘事件

请运行两次。 第一次在 Mac 闲置、盖子打开时运行，第二次在早上唤醒 Mac 之后立刻运行。主帖里的那位用户运行后没有发现持久的阻塞项：PreventSystemSleep、BackgroundTask 和 NetworkClientActive 都是 0，只有几条临时条目，比如一条来自 coreaudiod，以及一条与网络客户端相关的内核 assertion。有志愿者回复说，macOS 会创建大量临时 assertion，它们很少有助于找到原因。这与我们的经验一致：assertion 对「整夜醒着」的情况最有用，对「反复醒来」的情况最没用。

如果想看 assertion 被创建和释放的记录，pmset -g assertionslog 会实时输出，你也可以搜索历史记录：

pmset -g log | grep -E "Assertions" | grep -i "created" | tail -30

日志里的 assertion 行会写明持有进程和原因字符串，例如浏览器的「Video Wake Lock」，或「caffeinate command-line tool」条目。如果某个 App 整夜反复创建并释放 assertion，那它就是嫌疑对象。

命令 5：pmset -g 及相关命令，当前生效的设置

pmset -g
pmset -g custom
pmset -g cap
pmset -g sched

-g 打印正在使用的设置，-g custom 把电池和电源适配器分开显示，-g cap 列出这台 Mac 支持的功能，-g sched 列出计划中的唤醒。主帖里的那位用户的设置是 powernap = 1、tcpkeepalive = 1、womp = 0、standby = 1 和 hibernatemode = 3，都是笔记本的常规值。按手册说明，powernap 用来开关 Power Nap，womp 等同于「系统设置」里的「唤醒以供网络访问」，而 hibernatemode 3（便携设备的默认值）会让内存保持供电，同时在磁盘上保留一份副本。tcpkeepalive 没有出现在手册的设置列表中，但它出现在输出和日志里（TCPKeepAlive=active）。

有些指南说要立刻执行 tcpkeepalive 0 或 powernap 0。除了手册所述，我们没有在 macOS 27 上验证这些改动的实际效果，所以一次只改一项设置，并且只在测量结果指向它之后再改，同时记下旧值以便恢复。

App：活动监视器的「能耗」标签页，加上 top

打开活动监视器，点击能耗，按 12 hr Power 排序（右键点击表头可以添加这一列）。Preventing Sleep 列会显示哪个进程持有睡眠 assertion，把这个标签页与 pmset -g assertions 联系起来。一个 12 hr Power 很高但 CPU 占用很低的进程，很可能是在频繁唤醒 Mac，而不是在做计算，这正是唤醒日志所显示的。

在终端中：

top -l 2 -n 8 -o cpu -stats pid,command,cpu,idlew,power

-l 2 采样两次（第二次才有真正的差值），-n 8 显示八个进程，-stats 选择列。idlew 是空闲唤醒次数，power 是能耗评分；macOS 27.0.1 中的 top 都接受这两项，尽管手册中没有描述。即使 CPU 百分比看起来很小，较大的数值也能标出嫌疑对象。

读懂日志：看到什么、意味着什么、该怎么做

下面是决策表。其中的唤醒原因都是 macOS 27 上 pmset -g log 中真实出现的字符串；它们的含义是我们对字符串的解读，Apple 没有文档说明，所以请把第三列当作行动思路，而不是证据。

日志中看到什么	大概意味着什么	该怎么做
Clamshell Sleep 后面跟着长时间间隔，几乎没有 DarkWake	盖子合上，Mac 正常睡眠	无需处理；这就是健康的形态
大约每两小时一次 rtc/Maintenance 或 request=Maintenance	定时维护唤醒，上面示例中由 mDNSResponder 发起	正常
rtc/SleepService，并有一条 dasd 请求指明某个任务	由 DAS 调度的后台任务	在 Wake Requests 中查看任务名。同一个名字出现很多次就是线索
smc.sysState.Wake(0x70070000) wifibt SMC.OutboxNotEmpty	Wi-Fi/蓝牙芯片请求 SMC 唤醒	一晚几次属正常。每 15 分钟一次、多达几十次就是 10 月 8 日的那种模式；拔掉外接设备后再测试（见下文）
USB-C_plug、acdetach	电源或 USB 事件	物理层面的问题：扩展坞、集线器、充电器或线缆。拔掉后重新测试
UserActivity Assertion	有东西声明你处于活跃状态	蓝牙鼠标或键盘、触控板被碰到，或某个 App 调用了用户活跃 API。在 pmset -g assertions 中查找「Bluetooth LE HID Activity」
持续数分钟的 DarkWake	有东西在做真正的工作	抓取该时间窗口的统一日志（见下文），下次留意活动监视器
连续的 Wake Requests 都指向同一个进程	该进程在反复给自己安排唤醒	记下名字；如果是 dasd，就去搜索 info 字符串
powerd 发出的 InternalPreventSleep，名为 com.apple.powermanagement.darkwakelinger，随后超时	电源管理在 DarkWake 之后让 Mac 短暂保持清醒	短超时多半是例行现象；用户报告里列出了它，Apple 没有文档说明。看持续时间，不要看名字
整夜没有任何 Sleep 条目；Charge 稳步下降	Mac 从未睡眠	这就是「整夜醒着」的情况。运行 pmset -g assertions；检查盖子、外接设备、caffeinate、远程会话
睡眠日志正常，但 Charge 仍比以前掉得快得多	睡着了但仍在掉电	怀疑硬件或固件问题。参见电池健康部分

要深入查看某一次唤醒，请使用日志中的时间戳。主帖里有志愿者贴出了下面的模板，这是按起止时间读取统一日志的官方做法：

/usr/bin/log show --start "2026-10-14 03:14:00" --end "2026-10-14 03:16:00" --style compact > ~/Desktop/wake-window.txt

请使用你自己 pmset -g log 条目中、你想检查的那次 DarkWake 的准确时间，并把输出保存到文件，因为内容很多。这位志愿者还提醒说，这份日志里充满看似无害的错误和警告，要找出单一的元凶可能很困难，我们对此表示同意。如果你已经知道进程名（来自活动监视器或 Wake Requests），可以缩小搜索范围：

/usr/bin/log show --last 30m --style compact --predicate 'process == "powerd"'

--last 30m 限定时间窗口，--style compact 缩短每一行，--predicate 按进程或子系统过滤。把 powerd 换成你正在调查的进程。日志只保留有限的时间，所以请在事件发生后尽快运行。以普通用户身份运行；如果需要系统级条目，再加上 sudo。

Apple 芯片的不同之处

• 没有单独的 SMC 重置。 重启就相当于过去的重置；参见我们的 NVRAM、PRAM 和 SMC 指南。日志中仍会出现 smc.sysState 字符串，因为这些文字来自电源控制器。
• 可用的 pmset 键取决于具体机型。 pmset -g cap 会显示你的 Mac 支持什么。
• 便携设备默认开启休眠（hibernatemode 3），所以长时间睡眠在进入待机之前可能会损失一点电量。
• 唤醒原因字符串与 Intel 机型不同。 老文章引用的是 EC.LidOpen；在 Apple 芯片上则会看到 smc.sysState.Wake、NUB.SPMI、rtc/Maintenance，以及 wifibt 这样的具名硬件。Eclectic Light 的 2017 年详解解释了一次唤醒的结构，但其中的字符串是 Intel 时代的。

案例 1：replicatord 占满 100% CPU

Apple 支持帖子 「replicatord running at 100% CPU on macOS 27」 由一位 M1 Pro MacBook Pro 用户在 macOS 27.0 上于 9 月 17 日发布。结束进程或重启都没有用。我们阅读时，它有两条回复，没有「Me too」计数。

我们找不到 Apple 对 replicatord 的说明，也不会去猜。帖子里给出了一个方法，以及一个对某位用户有效的修复：

1. 一位志愿者建议保持 LaunchAgent 启用，在安全模式下测试，并使用活动监视器中的显示 > 取样进程。
2. 楼主的取样结果显示，CPU 时间「几乎全部花在 SQLite 数据库访问上」，因此他怀疑数据库已损坏。
3. 他用 lsof 在 ~/Library/Group Containers/group.com.apple.replicatord/replicatord/ 中找到了它。
4. 他重命名了 replicatord.sql、replicatord.sql-shm 和 replicatord.sql-wal，结束进程后，它「回来并创建了一个全新的数据库。CPU 占用现在恢复正常了」。

这是一位用户在一台 Mac 上报告的修复，未经 Apple 确认。以下是可恢复的尝试方式：

cd ~/Library/"Group Containers"/group.com.apple.replicatord/replicatord/
ls -la
mkdir -p ~/Desktop/replicatord-backup
cp -p replicatord.sql* ~/Desktop/replicatord-backup/
mv replicatord.sql replicatord.sql.old
mv replicatord.sql-shm replicatord.sql-shm.old
mv replicatord.sql-wal replicatord.sql-wal.old
killall replicatord

如果终端提示「Operation not permitted」，可能是 macOS 隐私保护阻止了访问；给终端授予「完全磁盘访问权限」是一种办法，但权限范围很广，所以用完后请移除。撤销方法： 运行 killall replicatord，删除新生成的 replicatord.sql* 文件，把 .old 文件改回原名，让进程重新启动。我们无法告诉你这个数据库里存了什么，这正是这些步骤选择重命名并备份、而不是直接删除的原因。如果 CPU 又回到 100%，请撤销并提交反馈。只有当 replicatord 确实出现在你的 CPU 占用列表里时，这个办法才有意义。

案例 2：agentstored，以及为什么目前还没有修复方法

MacRumors 上的一个帖子 「AgentStored process constantly running on Golden Gate」，我们在 10 月 14 日阅读时只发布了一两天，还没有回复。发帖人说，位于 /System/Library/PrivateFrameworks/AgentSessionKitRuntime.framework 下的 agentstored「一直在单个核心上占用 100%，即使刚重启之后也是如此」，「累计 CPU 时间 34 小时以上，向磁盘写入了约 39 GB」。关闭「自动视觉查询」，并把 AgentSessionKit 数据库移出 ~/Library/Daemon Containers，都没有帮助。

• 我们没有找到 Apple 对 agentstored 的任何说明，所以不会说它是做什么的。
• 目前没有已知的修复方法，而且这只是一份没有独立佐证的单一报告。

你仍然可以测量它。在活动监视器中，查看 CPU 标签页的 CPU 时间和磁盘标签页的写入的字节数，然后使用「显示 > 取样进程」，并保留取样结果用于「反馈助理」报告。不要把删除 ~/Library/Daemon Containers 中的文件当作实验；这位发帖人已经移走了一个数据库，没有效果。持续大量写入是尽早提交反馈的理由，而不是继续等待。

确实能减少睡眠耗电的设置

这些设置改变的是 Mac 的唤醒频率，不是在修 bug。我们对照 Apple 的 Mac 使用手册页面核对了路径，这些页面在版本选择器中把 macOS 27 排在最前。

设置	位置	备注
唤醒以供网络访问	系统设置 > 电池 > 选项（笔记本）；能源（台式机）	Apple 的页面说，选择较低频率的选项，例如仅在接通电源时或永不，可以省电。已核实
低电量模式 / 能源模式	系统设置 > 电池	电池和电源适配器分别设置。已核实
优化电池充电 / 充电限制	系统设置 > 电池，「充电」部分，信息按钮	保护电池寿命；不会减少睡眠耗电。已核实
Power Nap	pmset 的 powernap 键；旧版 macOS：电池 > 选项	手册中有说明；我们无法确认 macOS 27「系统设置」中的标签
蓝牙设备唤醒 Mac	原先位于 蓝牙 > 高级	2022 年的一个社区帖子称它在 Monterey 中被移除；我们无法确认它在 macOS 27 中的状态。睡眠前先关闭设备来测试
「查找」	Apple 账户和隐私设置	macOS 27 中的确切路径未确认；我们不建议把关闭它当作测试

有论坛回复还建议关闭「总结通知」，并检查「系统设置 > 通用 > 登录项与扩展」；后者在任何一次大版本升级之后都是个好习惯。要测试 Wi-Fi 或蓝牙，可以各关闭一晚，不过那位出现 wifibt 唤醒的用户发现，两者都关闭后唤醒仍在继续。

排查软件因素

主帖里有志愿者推荐了正确的拆分方法：

1. 安全模式。 在 Apple 芯片上，关机后按住电源按钮直到出现启动选项，选择启动磁盘，按住 Shift 键并选择「继续使用安全模式」。如果在那里日志是干净的，问题就出在第三方扩展或登录项上。
2. 新建用户账户。 如果它的过夜表现是干净的，原因就在你当前用户的设置或数据里。测完后把它删除。
3. 移除或更新清理软件、优化软件及类似程序，然后列出「登录项与扩展」，一组一组地禁用不熟悉的项目，并在不同夜晚之间比较每小时的 DarkWake 次数。

充电限制工具和菜单栏管理工具都需要针对 macOS 27 更新；参阅 macOS 27 上的充电限制 App。

什么时候该怀疑电池或硬件

如果日志显示睡眠长时间不间断，但电量仍然比以前掉得快得多，就要怀疑电池。

1. 打开系统设置 > 电池，点击电池状态旁的信息按钮。Apple 的 macOS 27 页面列出了电池状态和最大容量。
2. Apple 的电池服务页面把「正常」定义为「电池工作正常」，把「建议维修」定义为电池的蓄电能力不如新电池，或者没有正常工作。
3. 运行 system_profiler SPPowerDataType | grep -E "Cycle Count|Condition|Maximum Capacity"；「Health Information」部分包含这三个值。
4. 对于电量突降的情况，让 pmset -g pslog 在电池供电时一直运行。手册说，诸如从 30% 直接掉到 0 这样的不连续现象「说明电池已老化」。

发热问题参阅我们的 MacBook Pro M5 过热指南。电池健康、日志却不安分，那就是软件问题。

该向 Apple 提交什么

通往工程师的途径是「反馈助理」。Apple 的错误报告页面说它「会为每个问题自动附上 sysdiagnose」，并且 sysdiagnose「应该包含在所有报告中，即使你认为不需要」。如果没有开发者账户，Apple 的 macOS 反馈表单是更简单的网页途径。

1. 在糟糕的一晚之后尽快抓取 sysdiagnose。 sysdiagnose 手册给出的触发方式是 Control-Option-Command-Shift-句号；在终端中运行 sudo sysdiagnose 默认写入 /var/tmp，需要几分钟。它可能包含隐私信息。
2. 写明事实： macOS 27.0.1 (26A434)、Mac 型号、是升级安装还是全新安装，以及你的测试结果（起止电量百分比、时长、盖子状态）。
3. 附上 pmset -g log 的摘录和 pmset -g stats。
4. 点名嫌疑对象，附上 CPU 时间和写入字节数，以及你已经排除的因素：安全模式、新用户、可用空间。

不要这样做

• 不要安装「清理」或「优化」软件。 帖子里的志愿者说，这类软件会导致升级后的兼容性问题，而且没有一个能修复唤醒原因。
• 不要为了结束某个守护进程而关闭系统完整性保护（SIP）。 重命名的修复方法不需要这样的改动。
• 不要随意删除 LaunchAgents 或 LaunchDaemons。 有志愿者建议，在调查期间保持 Apple 的代理处于启用状态。
• 不要反复重置 SMC 或 NVRAM。 在 Apple 芯片上，重启就是重置；参阅我们的重置指南。
• 不要同时更改多项设置，也不要只凭一晚的结果下判断。
• 不要慌慌张张地抹掉磁盘降级。 先阅读更新决策指南和降级指南；原因可能只是某一个 App。

常见问题排查

我的日志显示整夜完全没有睡眠

症状：pmset -g log 在午夜到早晨之间没有任何 Sleep 条目，Charge 稳步下降。

原因：有东西让 Mac 一直醒着。候选对象包括 App 发出的 assertion（视频、下载、远程访问、caffeinate）、终端会话（ttyskeepawake 设置）、已连接的设备，或者没有完全合上的盖子。

解决方法：

1. 运行 pmset -g assertions，在「Listed by owning process」中查找 PreventUserIdleSystemSleep 或 PreventSystemSleep。
2. 在活动监视器的「能耗」标签页中，查看 Preventing Sleep 列。
3. 正常退出那个 App，然后重新测试。

pmset -g assertions | grep -E "PreventUserIdleSystemSleep|PreventSystemSleep|caffeinate"

如果仍然无效：断开所有外接设备，退出终端和远程会话，再做一次对照测试。如果 Mac 仍然从不睡眠，请在报告中附上 assertions 的输出。

Mac 大约每 15 分钟唤醒一次，原因里带有 wifibt

症状：DarkWake 条目按固定间隔出现，每条都写着 wifibt SMC.OutboxNotEmpty。

原因：无线芯片在反复请求系统唤醒。这与主帖上 10 月 8 日的报告相符，其中即使关闭了 Wi-Fi 和蓝牙，唤醒仍在继续。我们不清楚原因，Apple 也没有回应。

解决方法：

1. 用上面的 awk 命令按小时统计唤醒次数，并记下持续时间。
2. 移除蓝牙配件，并关闭附近与接力相关的设备，然后重新测试。
3. 在「系统设置 > 电池 > 选项」中把唤醒以供网络访问设为「永不」，并测试一晚。
4. 与开启低电量模式时的情况对比。

如果仍然无效：这适合作为「反馈助理」报告的候选。附上 DarkWake 次数，以及第二天早上抓取的 sysdiagnose。

pmset -g log 没有输出有用的内容，或 grep 什么都没返回

症状：过滤后输出为空，或者 log 报错。

原因：grep -E 'Sleep |Wake ' 这个模式依赖精确的空格数量。在 zsh 中，log 是 shell 内建命令，会报「too many arguments」。

解决方法：使用以事件列为依据的 awk 过滤，并用 /usr/bin/log show 读取统一日志。如果重启后 pmset -g log 是空的，让 Mac 多经历几个睡眠周期。

常见问题

macOS 27 睡眠时掉电快是已经确认的 bug 吗？

Apple 方面没有确认。使用 M3、M4 和 M5 MacBook 的用户在 Apple 社区论坛里描述了严重的过夜掉电，也有其他用户反映没有问题。我们没有找到 Apple 的确认，也没有已知问题条目，27.0.1 仅被描述为错误修复。请把它视为一个被广泛报告但未经证实的现象，在归咎于这次更新之前，先测量你自己的 Mac。

升级后 Spotlight 和「照片」需要多久？

Apple 没有公布时长，我们也没有找到官方数字。第三方指南提到几天。资料库的大小，以及 Mac 在接通电源时闲置的频率，都有影响。如果一台 Mac 在一周后合着盖子仍然发烫、持续掉电，就像主帖里那样，那么原因多半不只是索引。

DarkWake 是什么意思？它不好吗？

DarkWake 是一种部分唤醒，显示屏保持关闭，Mac 做一些简短的后台工作，比如维护、检查邮件或网络保活。每晚出现很多次是正常的。有论坛志愿者说，大多数持续不到一分钟。关键在于频率、持续时间，以及同一个原因是否反复出现。持续数分钟的 DarkWake 值得调查。

我可以放心地结束 replicatord 或重命名它的数据库吗？

唯一的证据是一位用户的报告：重命名其 Group Container 文件夹中的三个数据库文件并重启该进程后，CPU 占用恢复了正常。Apple 没有为这个进程提供文档。如果你要尝试，请先备份文件，重命名而不是删除，并且知道如何还原原文件。不要禁用该守护进程。

我应该关闭 Power Nap 或「唤醒以供网络访问」吗？

它们是合理的测试，不是根治办法。Apple 的页面说，为网络唤醒选择较低频率的选项可以省电，powernap 键在 pmset 手册中有说明。一次只改一项设置，做一次对照过夜测试，并比较 DarkWake 次数。我们无法确认 Power Nap 开关在 macOS 27「系统设置」中的位置。

降级回 Tahoe 能解决吗？

可能，但没有证据表明每个人都必须这样做，而且需要抹掉磁盘并重新安装。先测量：如果问题出在某个 App 或进程，移除它的成本要低得多。如果你的日志显示是 Mac 本身在反复唤醒，并且你无法忍受，降级指南会说明代价。

提交「反馈助理」报告时应该附上什么？

附上在糟糕的一晚之后尽快抓取的 sysdiagnose、你的 macOS 构建号（例如 27.0.1，26A434）、Mac 型号、来自 pmset -g log 的日志摘录，以及你的对照测试结果（起止电量百分比）。Apple 自己的页面说，每份报告都应附上 sysdiagnose，所以即使觉得多余也请附上。

总结

一些 MacBook 用户报告 macOS 27 下过夜掉电严重，Apple 没有任何表态，这些报告也没有指向单一原因。你能做的是测量：做一次对照过夜测试，读 pmset -g stats 和 pmset -g log 来判断 Mac 是睡着了、反复醒来，还是从未睡眠，检查 assertions 和活动监视器，并使用决策表。对于 replicatord，有一个用户报告的变通办法，可以在备份后尝试；对于 agentstored，目前只有一份清晰的报告可以提交。如果日志健康但电量掉得快，在归咎于软件之前，先检查电池健康。如果你判断这台 Mac 现在已经没法用，请参阅是否该更新和降级。

相关阅读：macOS 27 上 dasd 和 appstoreagent 夜间 CPU 占用过高、Mac 睡眠问题完全指南、macOS 27 之后的 Spotlight 重新索引