活动监视器“能耗”标签页需手动点击并等待5–10秒才显示数据，插电时“12小时电力”列为0，应关注“能耗影响”“防止睡眠”和“后台进程”三列交叉分析；高唤醒低单项进程（如mds_stores）比高瞬时值更伤续航。
活动监视器“能耗”标签页打不开或数据为空
这是最常遇到的第一道门槛：打开活动监视器后默认停留在“CPU”或“内存”页，不点进“能耗”就看不到任何耗电数据。macOS 不会自动切换，也不会在首次启动时预加载能耗指标。
必须手动点击顶部导航栏的 能耗 标签页；等待 5–10 秒，系统才完成采样并填充数值——期间若立即排序或退出，看到的可能是陈旧或零值数据。
常见错误现象包括：
- 误以为“能耗”页是实时刷新的，其实它依赖后台电源管理模块的周期上报（通常每 10–30 秒更新一次）
- 在 MacBook 未使用电池供电时（即插着电源），
12小时电力列可能不显示或恒为 0，此时应专注看能耗影响和防止睡眠 - 某些进程（如内核扩展、launchd 子任务）默认不显示在主列表，需勾选
显示>所有进程才能暴露真实后台负载
怎么准确识别“真·后台耗电大户”
很多用户只盯着“能耗影响”最高那一个应用，但真正拖垮续航的，往往是多个低单项但高频率唤醒的后台进程。比如一个 Electron 应用可能“能耗影响”只有 12，但它每分钟唤醒 CPU 3 次，持续拉高平均功耗。
关键要交叉比对三列：
-
能耗影响：看瞬时压力，适合定位正在疯狂跑任务的 App（如视频转码、AI 推理） -
防止睡眠：标记为“是”的进程会直接阻止 Mac 进入休眠，哪怕它当前没干活，也是续航隐形杀手（常见于 Zoom、Microsoft Teams、iTerm 插件等） -
后台进程（在进程名右侧有小字标注）：确认该条目是否真的在前台无窗口状态下持续运行，而非你刚切走的浏览器标签页
示例：如果 Google Chrome Helper (GPU) 的 能耗影响 高且 防止睡眠 为“是”，大概率是某个网页用了 WebGL 或 WebRTC，即使你最小化了窗口，它仍在后台渲染。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
强制退出后“能耗影响”不降反升？
这不是 bug，而是 macOS 的进程重建机制在起作用。比如你退出了 Dropbox，它的守护进程 dropbox_macos 可能在 2–3 秒后自动重启，并立刻触发一次高唤醒——此时你在活动监视器里看到的是新进程的初始峰值。
正确验证方式不是单次退出，而是：
- 先记下目标进程的 PID（鼠标悬停即可看到），退出后再观察同 PID 是否重现
- 配合菜单栏电池图标诊断：按住
Option键点击电池图标，等它列出“使用大量能量”的应用，和活动监视器比对是否一致 - 检查
防止睡眠列是否由其他进程接替（例如退出 Slack 后，NotificationCenter突然变成“是”，说明通知服务在代偿）
如果反复退出仍无效，大概率是通过 launchd 注册的开机自启服务，得去 ~/Library/LaunchAgents/ 或 /Library/LaunchDaemons/ 找对应 plist 文件禁用。
powermetrics 命令输出看不懂怎么办
sudo powermetrics --samplers cpu_power,gpu_power,smc 输出的是原始硬件功耗流，单位是毫瓦（mW），但默认不绑定进程名，新手容易迷失在滚动日志里。
实用技巧：
- 加
--show-process-gesti参数（注意拼写是 gesti，非 guess）才能关联进程与功耗，否则只看到 CPU/GPU 总体负载 - 输出中重点盯
Process CPU Power:和Process GPU Power:下方的块，每个块首行是进程名，后面跟着 mW 数值，数值稳定高于 200 mW 的就是可疑对象 - 不要长时间运行该命令——它本身就会增加约 5–8% 的额外 CPU 负担，建议只执行 30 秒，用
Control + C中断后复制粘贴关键段落到文本编辑器筛选
真正难排查的，从来不是那个“能耗影响”99 的浏览器，而是那个“能耗影响”只有 8 却每小时唤醒 127 次的 mds_stores——它不显眼，但把整机从深度睡眠拽出来几十次，实际耗电远超前者。
