電腦為什麼不會睡眠?用 powercfg /requests 找出阻止睡眠的程式

⚡ 站長快讀:核心重點

• 文章屬性:疑難排除
• 適用系統:Windows 10 / Windows 11(桌機、筆電皆適用)
• 難易度 / 耗時:⭐⭐ / 約 15 分鐘
• 核心結論:電腦不會睡眠,多半是某個程式或驅動送出了「電源要求(Power Request)」;powercfg /requests 可以直接把兇手的名字印出來,不必再靠猜的一個一個關程式。
• 適用對象:設定了睡眠時間卻從來沒生效、螢幕不關、或是筆電闔蓋帶出門後還在發燙的人。

📌 快速答案

一句話答案:電腦不會睡眠多半是某個程式或驅動送出了電源要求,以系統管理員身分執行 powercfg /requests,就能點名是哪個程式、哪支驅動擋住睡眠。

🧰 開始前的準備

• 適用系統:Windows 10、Windows 11(桌機與筆電;powercfg 為系統內建,不需另外安裝)
• 權限需求:系統管理員——powercfg 的多項診斷選項(如 /systemsleepdiagnostics、/systempowerreport)微軟官方明訂需由提升權限的命令提示字元執行,診斷全程建議一律用系統管理員身分開啟
• 需要工具:命令提示字元或 Windows 終端機(內建);報告類選項會在目前路徑產生 HTML 檔,建議先 cd 到桌面或某個空資料夾再跑
• 預計耗時:約 15 分鐘(含跑一次 60 秒的能源報告)

🔍 症狀描述與錯誤訊息

這類問題沒有錯誤視窗,也不會跳藍屏,所以特別難查。典型症狀長這樣:

「電源選項」裡明明設定「10 分鐘後進入睡眠」,結果離開兩小時回來,螢幕還亮著、風扇還在轉。手動點「開始 → 電源 → 睡眠」倒是進得去,就是自動進不去。

或者更麻煩的筆電版本:

蓋上蓋子塞進背包,一小時後拿出來,機身燙手、電量掉了一大半——它從頭到尾就沒真的睡著。

先做一個關鍵分流:請確認你遇到的是「根本沒進入睡眠」,還是「進去了但馬上被叫醒」。兩者的診斷路徑完全不同,搞錯方向會白花好幾個小時。判斷方法很簡單——手動點睡眠,如果它乖乖睡著而且維持著,那就是「自動睡眠被擋住」,本文的 powercfg /requests 正是為此而生;如果手動睡下去幾秒鐘又自己亮起來,那是喚醒來源的問題,請直接跳到本文的方法三。

🔎 問題根因

直接結論:Windows 的自動睡眠不是一個單純的倒數計時器,而是一個「所有人都同意才會睡」的協商機制。

Windows 內部維護著一份「電源要求(Power Request)」清單。任何一支程式或驅動程式,都可以向系統登記「我現在正在忙,請不要關螢幕」或「請不要進入睡眠」。只要清單上還有任何一筆有效的要求,閒置計時器就算歸零,系統也不會進入低耗電狀態。

微軟官方對 powercfg /requests 這個選項的說明就寫得很直白:它的作用是列舉應用程式與驅動程式的電源要求,而這些電源要求會阻止電腦自動關閉顯示器或進入低耗電睡眠模式。

換句話說,你的電腦不是「壞掉了」,也不是「電源計畫設定沒吃到」——它是忠實地執行了某個程式的請求。問題只在於,那個程式很可能忘了取消請求,或者根本是設計不良。官方文件其實直接點名了哪些程式「應該」登記:多媒體應用程式(影片播放、簡報)必須使用 ES_DISPLAY_REQUIRED;傳真伺服器、答錄機、備份代理與網路管理程式必須併用 ES_SYSTEM_REQUIRED 與 ES_CONTINUOUS;而文書處理、試算表、瀏覽器與遊戲不需要呼叫這支 API。這份官方名單很適合當作判讀的第一層濾網——清單上出現播放器或備份工具,那是設計如此,先排除。至於驅動程式,要說清楚一件事:powercfg 官方文件把 driver 與 process、service 並列為三種同等的正常呼叫者類型,官方從未表示驅動程式登記電源要求就是異常;不過就站長的實務經驗,驅動層的要求比應用程式難察覺、也較常出現「登記後沒清掉」的情況,所以值得優先追。這一句是經驗法則,不是官方判準,請這樣看待它。

這也是為什麼「重灌電源計畫」「把睡眠時間改短一點」通常沒用:那些設定調的是閒置多久才睡,而電源要求管的是能不能睡。兩者不在同一層。電源計畫本身怎麼調,是另一個層次的題目,文末延伸閱讀有專文可以接著看。

🔬 底層機制:這個「電源要求」到底從哪裡來?

程式並不是用什麼神秘手段擋住睡眠的,它呼叫的是一支公開的 Win32 API:SetThreadExecutionState。微軟官方文件對它的定義是——讓應用程式告知系統「我正在使用中」,藉此在該程式執行期間阻止系統進入睡眠或關閉顯示器。

它接受幾個旗標,對照 powercfg 的世界剛好一一對應:

有三個從官方文件讀出來的重點,是判讀 powercfg /requests 輸出時很實用的背景知識:

1. 不帶 ES_CONTINUOUS 的呼叫只會重設計時器一次,程式必須週期性地重複呼叫才能持續維持;反過來說,你在清單上看到的常駐要求,幾乎都帶了 ES_CONTINUOUS——而它必須由程式自己主動清除。程式當掉、被強制結束、或程式碼寫錯漏了清除,那筆要求就會一直掛在那裡。
2. 系統會自動偵測鍵盤、滑鼠輸入、伺服器活動與視窗焦點變化,但官方明講磁碟活動、CPU 活動與影片顯示畫面(video display)並不在自動偵測範圍內。這正是播放器與備份軟體非得主動登記不可的原因——它們不登記,系統根本不知道你在忙。
3. 這支 API 無法阻止使用者主動讓電腦睡眠,官方甚至補了一句:應用程式應該尊重使用者闔上筆電螢幕或按下電源鍵時的預期行為。所以「手動睡眠有效、自動睡眠無效」不是巧合,是設計上就這樣。

至於「離開模式(Away Mode)」則是另一個容易誤判的坑:官方說明它會讓任何原本會使電腦睡眠的操作,改為進入離開模式——電腦看起來像睡著了,實際上仍在執行不需要使用者輸入的工作。而且離開模式不影響睡眠閒置計時器,程式若要同時擋住睡眠,必須另外設定 ES_SYSTEM_REQUIRED。筆電在背包裡發燙,離開模式是嫌疑犯之一。

🛠️ 解決方案

⚠️ 開始前的提醒:以下步驟以「查詢」為主,方法四會變更系統的電源要求覆寫設定。動手前建議先建立一個系統還原點(控制台 → 系統 → 系統保護 → 建立),萬一設定改壞了可以整批還原。

方法一:powercfg /requests 直接點名元凶

以系統管理員身分開啟命令提示字元或 Windows 終端機,執行:

powercfg /requests

輸出會依電源要求的類型分成數個區塊。如果某個區塊底下寫著 無。(或 None.),代表該類型目前沒有任何人登記;真正有問題的那一區,則會直接印出登記者是哪一支處理程序、哪一個服務或哪一支驅動程式,通常還會附上它自報的理由字串。

判讀原則:

• 看到播放器、視訊會議、串流軟體——這是設計上的正常行為,關掉該程式或結束播放即可,不需要動系統設定。
• 看到備份、同步、下載工具——同樣正常,但要確認它是不是卡住了(工作已完成卻沒釋放)。
• 看到驅動程式——官方並未把驅動登記電源要求視為異常,但依站長的實務經驗,這一類最值得優先追。做法是到裝置管理員或原廠網站更新該裝置的驅動程式。
• 看到你完全不認得的處理程序——先查清楚它是什麼再動作,不要直接砍。

找到之後,先用最保守的方式處理:關閉該程式,再跑一次 powercfg /requests 確認那筆要求真的消失了。多數情況到這裡就結束了。

方法二:先確認你的機器「睡的是哪一種覺」

這一步是很多教學會漏掉的。現代筆電大量採用 Modern Standby(S0 低耗電閒置),它的行為和傳統 S3 睡眠差很多——在 Modern Standby 機器上,「螢幕關了但系統仍在低耗電運作」本來就是預期行為,你可能根本沒有「不會睡眠」的問題,而是「睡得不夠深」。

先查你的機器支援哪些睡眠狀態:

powercfg /availablesleepstates

官方對這個選項的說明是:回報系統可用的睡眠狀態,並嘗試回報某些睡眠狀態不可用的原因——最後那句「回報不可用的原因」特別有價值,它常常會直接告訴你是韌體不支援、還是被某個設定擋住。

如果確認是 Modern Standby 機型,診斷工具要換一把:

powercfg /sleepstudy

官方定義它會產生過去三天 Modern Standby 品質的診斷報告,並在目前路徑存成檔案。這份報告會列出每一段待機期間的耗電與活躍元件,比 /requests 的瞬時快照更適合抓「間歇性」的兇手。Modern Standby 的完整排查,站長另外寫過一篇Modern Standby (S0) 與 SleepStudy 深度檢測可以搭配著看。

想拉更長的觀察區間,還有兩個報告型選項。第一個是:

powercfg /systemsleepdiagnostics

它會產生一份報告,列出過去三天內使用者不在場的時間區間,以及系統當時究竟有沒有進入睡眠——這是驗證「到底睡了沒」最直接的證據。官方對這個選項明訂需要系統管理員權限、必須從提升權限的命令提示字元執行。

第二個是經典的能源效率報告(官方文件未對此選項標註權限需求,但建議照樣以系統管理員身分執行):

powercfg /energy

官方註明這個選項應該在電腦閒置、沒有開啟任何程式或文件時使用,預設觀察 60 秒後,會在目前路徑產生一份 HTML 報告。它抓的是廣義的能源效率問題,不限於睡眠,但常常能順手撈出被 /requests 漏掉的驅動層問題。

方法三:如果是「睡了又被叫醒」——查喚醒來源

如果你的症狀其實是睡下去幾秒或幾分鐘又自己醒來,那 /requests 是查不到東西的,要改查喚醒側。

先問系統「上次是誰把我叫醒的」:

powercfg /lastwake

官方定義:回報上一次睡眠轉換中,是什麼喚醒了系統。

再查有沒有排定的喚醒計時器:

powercfg /waketimers

官方定義:列舉作用中的喚醒計時器;若已啟用,喚醒計時器到期時會將系統從睡眠與休眠狀態喚醒。Windows Update、磁碟重組、備份排程都可能建立喚醒計時器。

最後查有哪些裝置被允許喚醒電腦:

powercfg /devicequery wake_armed

官方定義:列出目前被設定為可從任何睡眠狀態喚醒系統的裝置。滑鼠稍微碰一下就醒、或網路卡被區域網路封包吵醒,都是這裡查得到的。要逐一關掉這些裝置的喚醒權限,文末延伸閱讀有專文可以參考;至於睡下去完全叫不醒的相反情況,請看Windows 11 睡眠後無法喚醒完整解決教學。

方法四:powercfg /requestsoverride 強制忽略特定程式(最後手段)

當你確認某個程式就是不肯放手、又不能移除它時,Windows 提供了官方的覆寫機制:告訴系統「這個人的電源要求,你可以不理他」。

先看目前已經有哪些覆寫(不帶任何參數時,這個指令會顯示目前的覆寫清單,這是官方明訂的行為):

powercfg /requestsoverride

新增一筆覆寫的語法是 powercfg /requestsoverride <呼叫者類型> <名稱> <要求類型>。官方對三個參數的規定如下:

官方文件給的範例是:

powercfg /requestsoverride process wmplayer.exe display system

⚠️ 這裡有一個關鍵限制,大部分中文教學都沒寫:官方在 /requestsoverride 條目中明列的可覆寫要求類型只有 Display、System、Awaymode 三種——剛好對應前面那三個 SetThreadExecutionState 旗標。如果你在 powercfg /requests 的輸出裡看到的區塊類型不在這三種之內,那筆要求就不在官方可覆寫清單的範圍,硬套 /requestsoverride 是解不掉的,得回頭從更新驅動或移除該軟體下手。先搞清楚這一點,可以省下大量在論壇上抄指令卻無效的時間。

✅ 驗證修復結果

不要只看「今天晚上好像有睡著」就結案,請照順序做完這三件事:

1. 即時驗證:處理完之後立刻再跑一次 powercfg /requests,確認原本那筆要求已經從清單上消失。
2. 行為驗證:把電腦閒置到超過設定的睡眠時間,確認它真的自動睡著。若是 Modern Standby 機型,改看 powercfg /sleepstudy 產生的報告。
3. 回溯驗證:隔一兩天後跑 powercfg /systemsleepdiagnostics,用它產生的「使用者不在場區間 + 是否進入睡眠」報告當客觀證據——這一步能抓出「只有某些情境才復發」的間歇性問題,是單次目視觀察做不到的。

停止條件(符合任一,請先停下再往下做):不確定 powercfg /requests 印出的處理程序是什麼、公司或學校管控的設備但沒有 IT 授權、指令輸出與本文描述明顯不符、或是尚未建立系統還原點。

🔙 萬一翻車:回退步驟

情境一:覆寫加錯對象,反而讓該用的程式被打斷。

官方文件並未明載「移除單筆覆寫」的語法,所以請不要照抄論壇上未經證實的寫法。官方明訂:在命令列加上 /? 會顯示指定選項的說明——先跑 powercfg /requestsoverride /? 叫出該選項在你這台機器上的內建說明,依實際說明操作最保險;不確定就直接跳到情境二用系統還原點整批還原。查核時再跑一次不帶參數的 powercfg /requestsoverride,即可確認清單上還剩哪幾筆。

情境二:改了一堆設定後搞不清楚動過什麼。

用先前建立的系統還原點還原(控制台 → 系統 → 系統保護 → 系統還原)。這也是為什麼方法四動手前一定要先建立還原點。

情境三:電源計畫本身被改亂。

在電源選項中對使用中的電源計畫按「還原此計畫的預設值」,或直接切換回 Windows 內建的「平衡」計畫。

💡 總結:預防再次發生

站長我處理這類案子的順序永遠是固定的:先分流(不會睡 vs 睡了被叫醒)→ 再點名(/requests 或 /lastwake)→ 最後才動設定。跳過前兩步直接去改電源計畫,是我看過最常見的浪費時間方式——因為電源計畫管的是「閒置多久才睡」,電源要求管的是「能不能睡」,調錯層級當然無效。

長期預防有三個原則。第一,把裝置驅動程式保持更新:這是站長的經驗法則而非官方判準——驅動與其隨附服務造成的殘留要求最難自己察覺,更新往往就解掉了。第二,別急著用 /requestsoverride 蓋台——覆寫是把系統的判斷關掉,如果那個程式真的在傳資料,你可能換來一個中斷的備份;能關程式就關程式,能修驅動就修驅動。第三,留一份基準線:在系統正常的時候跑一次 powercfg /requests 存起來,日後出問題時就有得比對,不必從零開始猜。

最後,如果你的需求其實剛好相反——你是刻意希望電腦不要自動關螢幕、不要進入睡眠——那不需要靠任何程式擋著,Windows 本來就有正規設定可以做到,做法請看如何防止電腦自動關閉螢幕與自動進入睡眠。

❓ 常見問題

Q:powercfg /requests 一定要用系統管理員身分執行嗎?

強烈建議是。powercfg 的多個診斷選項(例如 /systemsleepdiagnostics、/systempowerreport)微軟官方明訂必須從提升權限的命令提示字元執行;既然整套排查會用到這些指令,一開始就用系統管理員身分開啟終端機最省事,也避免因權限不足看到不完整的結果。

Q:清單上顯示的是 [DRIVER] ... 之類的驅動程式,我可以直接停用那個裝置嗎?

不建議把停用裝置當第一步。先更新該裝置的驅動程式,多數「登記後忘了取消」的問題會隨新版驅動消失。停用裝置等於放棄該硬體功能,而且如果停用的是網路卡或儲存控制器,可能連開機都受影響。

Q:我照著網路教學下了 /requestsoverride,但完全沒效果?

先確認你要覆寫的要求類型有沒有落在官方允許的 Display、System、Awaymode 三種之內。不在這三種內的要求類型,/requestsoverride 就吃不下去。另外也請確認「呼叫者類型」有沒有選對——process、service、driver 是三種不同的東西,要以 powercfg /requests 輸出的實際歸類為準。

Q:修完之後又復發怎麼辦?

改用觀察期較長的工具:powercfg /sleepstudy 與 powercfg /systemsleepdiagnostics 都是產生過去三天的報告,適合抓間歇性問題。找出復發的時間點後,回頭比對那個時段有什麼排程任務、更新或連接的裝置。

🔗 延伸閱讀

• Windows 省電還是效能?「電源計畫」設定完全指南
• Win10/Win11 如何關閉滑鼠鍵盤喚醒電腦功能?
• 筆電放在包包裡自動「發燒」?徹底關閉 Windows 睡眠,改用「休眠」
• Win10/Win11 如何重新開啟休眠(Hibernate)模式?
• 揭秘 Windows「快速啟動」的技術債與關閉指南

📎 參考資料來源

📖 第一級|廠商官方:

• Powercfg command-line options — Microsoft Learn — 2026-07-22 查證
• SetThreadExecutionState function (winbase.h) — Microsoft Learn — 2026-07-22 查證

⚠️ 本文核心事實以第一級為準。本文所有指令定義與參數限制均取自上列微軟官方文件。

📅 本文查證戳記:2026-07-22 依據 Windows 10 / Windows 11 之微軟官方文件撰寫。

若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。