<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>电池耗电 on Zero Day Notes</title>
        <link>https://blog.5772447.xyz/tags/%E7%94%B5%E6%B1%A0%E8%80%97%E7%94%B5/</link>
        <description>Recent content in 电池耗电 on Zero Day Notes</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh</language>
        <lastBuildDate>Fri, 23 Oct 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://blog.5772447.xyz/tags/%E7%94%B5%E6%B1%A0%E8%80%97%E7%94%B5/index.xml" rel="self" type="application/rss+xml" /><item>
            <title>S0 待机被网卡唤醒：笔记本合盖后持续掉电</title>
            <link>https://blog.5772447.xyz/posts/5a0f78a3/</link>
            <pubDate>Fri, 23 Oct 2026 09:00:00 +0800</pubDate>
            <guid>https://blog.5772447.xyz/posts/5a0f78a3/</guid>
            <description>&lt;h2 id=&#34;问题背景&#34;&gt;&lt;a href=&#34;#%e9%97%ae%e9%a2%98%e8%83%8c%e6%99%af&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;问题背景&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;公司今年分两批换了 60 台商务本，预装 Windows 11，默认启用 Modern Standby。员工的使用习惯很统一：下班把笔记本合盖装进包里，或者插在工位扩展坞上，第二天上班再打开，很少有人真正关机。&lt;/p&gt;&#xA;&lt;p&gt;最近两个月，陆续有 8 台机器反馈“合盖一晚上，第二天从包里拿出来是热的，电量还掉了不少”。其中一位同事周五满电放进包里，周一开机只剩四成电。IT 起初按电池老化处理，换了两块电池，问题照旧，才开始往电源策略方向查。&lt;/p&gt;&#xA;&lt;h2 id=&#34;故障现象&#34;&gt;&lt;a href=&#34;#%e6%95%85%e9%9a%9c%e7%8e%b0%e8%b1%a1&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;故障现象&#xD;&#xA;&lt;/h2&gt;&lt;ul&gt;&#xA;&lt;li&gt;合盖后笔记本装在包里，外壳明显温热，偶尔能听到风扇转一下又停。&lt;/li&gt;&#xA;&lt;li&gt;电量下降没有规律：有的机器一晚掉 10%，有的掉 30% 以上；周末放置掉得更多。&lt;/li&gt;&#xA;&lt;li&gt;拔掉 USB-C 扩展坞后，掉电明显减轻，但没有完全消失。&lt;/li&gt;&#xA;&lt;li&gt;&lt;code&gt;powercfg /a&lt;/code&gt; 显示系统只支持“待机（S0 低功耗空闲）”，S3 状态不可用，固件不支持传统睡眠。&lt;/li&gt;&#xA;&lt;li&gt;&lt;code&gt;powercfg /sleepstudy&lt;/code&gt; 生成的报告里，一次约 14 小时的合盖会话中，Low Power Idle 只占三成多，其余时间系统处于 Active；报告同时列出了若干唤醒源。&lt;/li&gt;&#xA;&lt;li&gt;电池报告显示设计容量与满充容量衰减不到 10%，电池健康度正常。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;排查过程&#34;&gt;&lt;a href=&#34;#%e6%8e%92%e6%9f%a5%e8%bf%87%e7%a8%8b&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;排查过程&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;第一步先排除电池。用 &lt;code&gt;powercfg /batteryreport&lt;/code&gt; 对比设计容量和满充容量，衰减在正常范围内；换过电池的机器现象不变，说明不是电芯问题。&lt;/p&gt;&#xA;&lt;p&gt;第二步确认系统到底进了什么睡眠状态。&lt;code&gt;powercfg /a&lt;/code&gt; 的输出很关键：这台机器支持的是 S0 低功耗空闲，S3 显示为“固件不支持”。也就是说，合盖并没有让机器断电休眠，而是进入一种“保持联网、随时可被唤醒”的低功耗状态。这是 Modern Standby 的设计，本身不是故障，但它意味着“合盖”不等于“停止工作”。&lt;/p&gt;&#xA;&lt;p&gt;第三步看睡眠质量。运行 &lt;code&gt;powercfg /sleepstudy&lt;/code&gt; 生成 HTML 报告，重点看三处：Low Power Idle 占比、Active 时段、唤醒源。问题机器的报告里，Low Power Idle 只占三成多，大量时间在 Active；唤醒源列表里反复出现 USB 以太网设备和无线网卡。&lt;/p&gt;&#xA;&lt;p&gt;第四步确认唤醒权限。&lt;code&gt;powercfg /devicequery wake_armed&lt;/code&gt; 列出当前被允许唤醒系统的设备，扩展坞网卡和无线网卡都在列表里；&lt;code&gt;powercfg /lastwake&lt;/code&gt; 指向的正是 USB 网卡。再结合使用场景：这几台问题机器要么长期插着扩展坞，要么包里带着扩展坞、网线还接着。夜间网络里的 DHCP、ARP、组播流量，以及网卡的“唤醒模式匹配”，都可能把系统从低功耗拉回 Active。&lt;/p&gt;&#xA;&lt;p&gt;第五步验证。选一台问题机器，禁用网卡唤醒、关闭电池模式下的待机联网，再观察一晚：sleepstudy 显示 Low Power Idle 从三成多升到九成以上，整夜掉电从近三成降到个位数。变量唯一，结论成立。&lt;/p&gt;&#xA;&lt;h2 id=&#34;解决方案&#34;&gt;&lt;a href=&#34;#%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;解决方案&#xD;&#xA;&lt;/h2&gt;&lt;ol&gt;&#xA;&lt;li&gt;&lt;strong&gt;关闭不必要的唤醒源&lt;/strong&gt;：设备管理器里找到有线网卡、无线网卡和扩展坞网卡，在“电源管理”中取消“允许此设备唤醒计算机”；同时在网卡高级设置里关闭 Wake on Magic Packet 和“唤醒模式匹配”。也可以用 &lt;code&gt;powercfg /devicedisablewake &amp;quot;设备名&amp;quot;&lt;/code&gt; 批量处理。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;关闭电池模式下的待机联网&lt;/strong&gt;：通过组策略或 Intune 把“Allow network connectivity during connected-standby (on battery)”设为 Disabled。合盖后网络断开，邮件、网盘、更新等后台同步就不会持续把机器拉活。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;关闭电池下的唤醒定时器&lt;/strong&gt;：执行 &lt;code&gt;powercfg /setdcvalueindex scheme_current sub_sleep bd3b718a-0680-4d9d-8ab2-e1d2b4ac806d 0&lt;/code&gt;，避免 Windows 更新、备份等计划任务在夜里唤醒机器。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;更新驱动和固件&lt;/strong&gt;：扩展坞固件、网卡驱动、芯片组驱动统一到厂商推荐版本。部分旧固件会在待机时反复重新枚举 USB 设备，把系统从低功耗里拽出来。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;设置休眠兜底&lt;/strong&gt;：对经常出差的机器启用休眠，并把电池模式下的“在此时间后休眠”设为 45 分钟。即使待机被异常唤醒，最终也会落盘休眠，不会整夜耗电。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;不要强行禁用 Modern Standby&lt;/strong&gt;：多数新平台不支持 S3，改注册表关闭 S0 可能导致无法睡眠、唤醒异常甚至无法关机。正确做法是治理唤醒源，而不是和平台能力对抗。&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;h2 id=&#34;根因分析&#34;&gt;&lt;a href=&#34;#%e6%a0%b9%e5%9b%a0%e5%88%86%e6%9e%90&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;根因分析&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;直接根因是 &lt;strong&gt;Modern Standby 下扩展坞网卡保持可唤醒状态，夜间网络流量反复把系统从低功耗拉回 Active，CPU、网络和后台同步持续工作，电量以“待机”的名义被消耗&lt;/strong&gt;。&lt;/p&gt;&#xA;&lt;p&gt;更深一层，问题出在对“合盖”的认知错位。传统 S3 睡眠是断电，合盖就是停机；Modern Standby 把睡眠改成了“低功耗联网”，目的是即时唤醒和后台更新。功能本身没错，但默认策略没有区分插电和电池，也没有治理唤醒源。用户以为笔记本在休息，系统其实在包里继续上班。另一个偏差是把发热掉电直接归因于电池老化，换了电池才发现问题在策略层。&lt;/p&gt;&#xA;&lt;h2 id=&#34;预防措施&#34;&gt;&lt;a href=&#34;#%e9%a2%84%e9%98%b2%e6%8e%aa%e6%96%bd&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;预防措施&#xD;&#xA;&lt;/h2&gt;&lt;ul&gt;&#xA;&lt;li&gt;新机型入网做 sleepstudy 基线：电池模式下合盖 8 小时，Low Power Idle 应高于 85%、掉电低于 5%；不达标不批量发放。&lt;/li&gt;&#xA;&lt;li&gt;扩展坞选型增加待机行为测试，固件统一版本，避免个别型号在待机时反复唤醒主机。&lt;/li&gt;&#xA;&lt;li&gt;用 Intune 或组策略统一电池模式下的待机联网、唤醒定时器和网卡唤醒策略，不依赖员工手动设置。&lt;/li&gt;&#xA;&lt;li&gt;资产巡检把 sleepstudy 异常纳入报表：Active 占比高、夜间唤醒次数多、待机掉电超阈值的机器主动排查。&lt;/li&gt;&#xA;&lt;li&gt;给员工的指引要具体：周末和长假前关机或休眠，不要把“合盖”当成关机。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;总结&#34;&gt;&lt;a href=&#34;#%e6%80%bb%e7%bb%93&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;总结&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;Modern Standby 不是“更省电的睡眠”，而是“让电脑在合盖后继续低功耗地工作”。它把选择权交给了设备和后台任务：谁能唤醒、何时联网，决定了包里那台机器是在休息还是在加班。把唤醒源当成资产管理项，比反复争论“为什么待机还耗电”有用得多。&lt;/p&gt;&#xA;&lt;h2 id=&#34;延伸阅读&#34;&gt;&lt;a href=&#34;#%e5%bb%b6%e4%bc%b8%e9%98%85%e8%af%bb&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;延伸阅读&#xD;&#xA;&lt;/h2&gt;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/6d0ad74e/&#34; &gt;终端休眠后无法唤醒：快速启动与网卡唤醒冲突&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/cfb90b2b/&#34; &gt;USB-C 扩展坞接双屏为何没信号？桌面排障记&lt;/a&gt;&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;</description>
        </item></channel>
</rss>
