WP-Cron 是什麼?原理與改用真 cron 完整教學

系統需求:自架(self-hosted)WordPress;WordPress.com 免費/入門方案或部分全代管主機不開放自訂系統排程
權限需求:能編輯 wp-config.php(FTP / SSH / 主機檔案管理員),以及能設定主機排程(cPanel Cron Jobs、SSH crontab,或 Windows 工作排程器)
需要工具:文字編輯器或檔案管理員;(選用)WP-CLI、WP Crontrol 外掛
預計耗時:約 20 分鐘
難度門檻:會用 FTP / 檔案管理員改一行設定、看得懂主機後台的「Cron Jobs」欄位就能做

🔍 為什麼你需要搞懂 WP-Cron

排程文章時間到了卻沒發、電子報外掛顯示「已排程」卻遲遲沒寄出、每日備份三天才跑一次——這些「排程沒準時」的問題,十之八九都跟 WP-Cron 有關。另一種相反的災情是:明明是小站,主機商卻寄信來說 wp-cron.php 佔用太多資源、把 CPU 吃滿。

這兩種看似矛盾的狀況,其實源自同一個設計:WordPress 的排程不是真正的作業系統排程,而是一套「有人來才會動」的機制。搞懂它怎麼運作,你才知道自己該加把勁催它、還是該幫它踩剎車。這篇會先把原理講清楚,再帶你用官方支援的方式,把假 cron 換成真正準時的系統 cron。

🕐 WP-Cron 到底是什麼:一個「有人來才動」的假 cron

先講結論:WP-Cron 是 WordPress 模擬出來的排程系統,它只在「網頁被載入」的那一刻,才去檢查有沒有到期的排程任務。

根據 WordPress 官方外掛開發手冊,WP-Cron 負責處理 WordPress 裡所有跟時間有關的排程任務——檢查核心與外掛更新、發布排程文章等等,都靠它。名字裡的「Cron」來自 UNIX 系統的 cron 排程器,但兩者運作方式差很多。

真正的系統 cron 是常駐在作業系統裡的服務,時間一到就準時執行,不管有沒有人在用這台機器。WP-Cron 不一樣:它在每次頁面載入時,檢查一份排程任務清單,看有哪些該跑了,到期的任務就在那次頁面載入時被呼叫執行。官方文件講得很直白:WP-Cron 不像系統 cron 那樣持續運行,它只有在頁面載入時才被觸發。

官方甚至舉了一個例子點出它的罩門:如果你把任務排在下午 2:00,但一直到下午 5:00 才有人打開你的網站,那這個任務就會拖到 5:00 才執行。

它是用「間隔秒數」在模擬排程

還有一個和系統 cron 不同的地方:系統 cron 可以指定「每小時的第 5 分鐘」這種精確時間點,WP-Cron 則是用「間隔秒數」來模擬。官方文件說明,WP-Cron 拿到的是兩個參數——第一次執行的時間,以及之後重複的間隔(以秒為單位)。WordPress 內建幾個預設間隔:

hourly(每小時)
twicedaily(每天兩次)
daily(每天)
weekly(每週,自 WordPress 5.4 起才內建)

開發者也能透過 cron_schedules 這個 filter 自訂間隔。這裡先記住一件事:WP-Cron 是用間隔在跑,而且所有間隔都以秒計。

⚠️ 為什麼「假 cron」會出問題

先講一句:問題不是 WP-Cron 有 bug,而是它把「排程準不準」跟「網站有沒有流量」綁在一起了。 官方文件也說明了這套設計的原因:很多主機是共享主機,使用者根本碰不到系統排程器;用 WordPress 內建的 API 排程,比跑到系統層設定簡單得多;而且任務會進佇列,就算晚了也「終究會執行」。對大多數中小型網站,這套機制其實夠用。問題出在兩個極端。

低流量站:排程「漏跑」或嚴重延遲

如果你的部落格一天沒幾個訪客,頁面載入次數少,WP-Cron 被觸發的機會就少。結果就是排程文章沒準時發、電子報延遲好幾小時、備份外掛的排程一直往後拖。這正是官方那個「排 2:00、拖到 5:00 才跑」例子的真實版本。

高流量站:`wp-cron.php` 被打太兇,拖累效能

反過來,如果你的站流量很大,幾乎每一次頁面載入都可能觸發一次 WP-Cron 檢查,wp-cron.php 就會被頻繁呼叫。雖然 WordPress 有一個鎖(lock)機制擋住短時間內的重複觸發(預設 60 秒,由 WP_CRON_LOCK_TIMEOUT 常數控制),但在高並發下,這仍是一筆可觀的額外負擔。很多主機商所謂「WP-Cron 吃資源」的告警,講的就是這件事。

還有一種:loopback 被擋,WP-Cron 根本沒在跑

WP-Cron 靠 WordPress 對自己發出一個內部請求(loopback)來運作。如果主機防火牆、安全外掛或伺服器設定擋掉了這個自我請求,WP-Cron 可能完全不會被觸發。想確認站上的排程有沒有正常運作,可以先從 WordPress 內建工具下手——我在 WordPress 網站健康狀況完整教學裡整理過,「網站健康狀況」的測試就包含「有排程遺漏的事件」與 loopback 請求的檢查,是最快的第一步。

🔎 動手前先診斷:你的 WP-Cron 現在正常嗎

別急著關掉 WP-Cron,先確認它到底有沒有問題。三個由淺入深的檢查法:

1. 網站健康狀況(免安裝): 後台 工具 → 網站健康 → 狀態,若看到「有排程遺漏的事件」或 loopback 請求失敗的警告,代表 WP-Cron 觸發有狀況。

2. WP Crontrol 外掛(圖形化): 這是 WordPress.org 官方外掛庫裡老牌的排程管理工具,裝了之後能在 工具 → Cron 事件 看到所有排程任務、下次執行時間,也能手動觸發或刪掉卡住的事件。

3. WP-CLI(指令列,最精準): 如果主機能用 SSH 跑 WP-CLI,這是最乾淨的方式:

# 列出所有排程事件與下次執行時間
wp cron event list

# 立刻執行「現在就到期」的所有事件
wp cron event run --due-now

官方 WP-CLI 文件對 wp cron event run --due-now 的說明是「執行所有現在到期的 hook」,跑完會回報類似 Success: Executed a total of 2 cron events. 的結果。用它就能當場驗證排程到底跑不跑得動。

🛠️ 實戰:關掉假 cron、改用系統 cron

確認問題後,官方推薦的解法只有兩步:先在 wp-config.php 關掉內建的 WP-Cron,再用主機的系統排程去定時呼叫 wp-cron.php。

⚠️ 動手前先備份 wp-config.php。 這個檔案是 WordPress 的核心設定,少一個分號、多一個字元都可能讓整站變白畫面。改之前先把原檔下載一份,或在主機複製成 wp-config.php.bak。

步驟一:在 wp-config.php 關掉內建 WP-Cron

用 FTP 或主機檔案管理員打開網站根目錄的 wp-config.php,在 /* That's all, stop editing! */(「就這樣,別再往下編輯了」)這行上方,加入官方指定的這一行:

define( 'DISABLE_WP_CRON', true );

這行的意思是「不要再靠頁面載入觸發 WP-Cron」。注意:關掉之後、還沒設好系統 cron 之前,你站上所有排程都會停擺,所以請接著馬上做步驟二。

步驟二(Linux / 一般虛擬主機):用 crontab 或 cPanel 定時呼叫

如果你能用 SSH,直接編輯 crontab:

crontab -e

Cron 的語法是「分時日月週指令」五個時間欄位加一個指令。官方文件示範用 wget 呼叫 wp-cron.php,例如每 15 分鐘跑一次:

*/15 * * * * wget --delete-after https://你的網域/wp-cron.php

--delete-after 是必要的:官方特別提醒,少了它,wget 會把每次請求的回應內容存成檔案,久了塞爆空間。若主機是 cPanel,則到後台 Cron Jobs 欄位填同一條指令即可,不必碰 SSH。

更推薦:用 WP-CLI 取代打網址。 直接呼叫 PHP、不繞一圈 HTTP,更乾淨也更可靠:

*/15 * * * * cd /你的網站根目錄 && wp cron event run --due-now

步驟二(Windows Server):工作排程器

如果 WordPress 跑在 Windows 主機,官方建議用工作排程器(Task Scheduler)建立一個「基本工作」,執行這行 PowerShell:

powershell "Invoke-WebRequest https://你的網域/wp-cron.php"

再依你想要的頻率設定觸發間隔即可。

步驟三:驗證有沒有生效

設好之後,等一個排程間隔,再用前面的 wp cron event list 看事件的「下次執行時間」有沒有正常往前推;或乾脆排一篇測試文章在幾分鐘後發布,看它會不會準時上稿。能用 WP-CLI 的話,wp cron event run --due-now 手動催一次是最快的確認。

🧨 三個最容易踩的雷

系統 cron 間隔別設得比 60 秒還短。 WordPress 內建的鎖機制(WP_CRON_LOCK_TIMEOUT,預設 60 秒)本來就會擋掉 60 秒內的重複觸發,你排每 30 秒呼叫一次只是白費力氣。一般網站設每 5 到 15 分鐘一次就很夠。
排程文章老是沒準時發,但還不想改系統 cron?先試 ALTERNATE_WP_CRON。 在 wp-config.php 加 define( 'ALTERNATE_WP_CRON', true ); 會改用「重導向」方式觸發排程,適合主機擋掉自我 loopback 請求的情況。缺點是它依賴訪客的瀏覽器被重導一下,不是每種佈景都乾淨,算是沒有系統 cron 時的折衷。
關了 WP-Cron 卻忘了設系統 cron = 排程全停。 這是最常見的翻車:DISABLE_WP_CRON 一加,若沒有任何外部排程接手,備份、更新檢查、排程發文全部不會動。兩件事要一起做完。

🔙 萬一翻車:回退步驟

情境一:改完 wp-config.php 後整站白畫面。 多半是這一行貼錯位置或打錯字。用 FTP / 檔案管理員把剛剛備份的 wp-config.php.bak 還原回去,或把你加的那行刪掉存檔,網站就會恢復。

情境二:排程全部停擺、但一時設不好系統 cron。 先把 wp-config.php 裡的 define( 'DISABLE_WP_CRON', true ); 這行刪掉(或改成 false),WordPress 就會退回原本靠流量觸發的內建 WP-Cron,至少排程會再次運作,之後再從容設定系統 cron。

💡 總結:什麼時候該改、什麼時候別瞎忙

先說老實話:這篇是站長我根據 WordPress 官方文件整理的原理與操作,不是宣稱哪一台特定主機的實測數字。但這麼多年管站下來,WP-Cron 的判斷邏輯其實很單純,可以濃縮成一句:「排程有沒有準時」比「wp-cron.php 吃多少資源」更值得先擔心。

如果你是流量普通的個人站、部落格,排程也都算準時,那其實不用動它——WordPress 這套「終究會執行」的設計對你剛剛好,亂改系統 cron 反而多一個會壞的環節。真正該改用系統 cron 的,是這幾種:排程文章或電子報常常遲到、跑電商或會員站有「非準時不可」的任務、或流量大到主機商已經在抱怨 wp-cron.php。

還有一個常被忽略的點:WP-Cron 的鎖是存成 WordPress transient(暫存資料)的,而 transient 就住在資料庫的 wp_options 表裡。排程任務一多、外掛一雜,這張表很容易變肥、拖慢每一次查詢——這部分我在 WordPress 資料庫優化裡有詳細講怎麼清。把排程和資料庫一起顧好,WordPress 後台才會真的順。

❓ 常見問題

Q:關掉 WP-Cron 會不會讓排程文章發不出去?

只要你有正確設好系統 cron 接手,就不會,反而更準時。真正危險的是「關了 WP-Cron 卻沒設系統 cron」,那才會讓所有排程停擺。兩件事一定要一起做完。

Q:我用的是 WordPress.com 或全代管主機,也能這樣改嗎?

不一定。這篇的做法針對「能改 wp-config.php、能設系統排程」的自架站。WordPress.com 的免費/入門方案和部分全代管平台不開放自訂系統 cron,它們通常已在平台層幫你接管排程,照官方或客服說明處理即可。

Q:一定要用 WP-CLI 嗎?用 wget 打網址不行嗎?

兩種官方都支援。wget / Invoke-WebRequest 打 wp-cron.php 最通用、幾乎任何主機都能設;WP-CLI 直接呼叫 PHP、不繞 HTTP,更乾淨也好排錯,前提是主機裝得了 WP-CLI。挑你環境能跑的即可。

Q:系統 cron 間隔要設多久?

一般網站每 5 到 15 分鐘一次就很夠;有「非準時不可」任務的再縮短,但別短於 60 秒(會被 WP_CRON_LOCK_TIMEOUT 擋掉)。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|WordPress 官方:

Cron — Plugin Handbook(What is WP-Cron) — 2026-07-04 查證
Understanding WP-Cron Scheduling — 2026-07-04 查證
Hooking WP-Cron Into the System Task Scheduler — 2026-07-04 查證
WP-CLI:wp cron event run — 2026-07-04 查證
Editing wp-config.php(Advanced Administration Handbook) — 2026-07-04 查證

📖 第二級|權威補充(鎖機制與常數細節,非官方最終權威):

SpinupWP — Understanding WP-Cron — 2026-07-04 查證
WP Crontrol — WP_CRON_LOCK_TIMEOUT 說明 — 2026-07-04 查證

⚠️ 本文核心事實以第一級 WordPress 官方文件為準,第二級僅補充鎖機制與常數細節。

📅 本文查證戳記:2026-07-04 依 WordPress 官方外掛開發手冊與 WP-CLI 文件撰寫。WordPress 版本演進若導致預設排程或行為變動,歡迎在留言區回報,站長會更新。