如何解決 WordPress 中「目前正在執行另一項更新程序」導致無法升級/更新的問題

當你在 WordPress 後台準備更新核心版本或外掛時，突然跳出一段紅色警告訊息：「目前正在執行另一項更新程序」（英文原文為 Another Update in Process），整個更新頁面被鎖住，什麼都不能點。這不是什麼罕見的系統故障，也不是網站被入侵的跡象。這其實是 WordPress 內建的更新保護機制在發揮作用，只是偶爾它會「過度盡責」，該解鎖的時候沒有正常釋放。

簡單來說，WordPress 為了避免同一時間有多個更新程序同時寫入資料庫，設計了一套鎖定機制（這跟Blogger 等託管平台不同，自架 WordPress 讓你對更新流程有完全的控制權）。當系統偵測到有更新正在進行中，就會自動擋下所有新的更新請求，並顯示這段提示訊息。在正常的情況下，這個鎖定會在更新完成後自動解除，或是等待最多 15 分鐘後過期。但問題就出在「不正常」的情況，比如說更新程序中途因為伺服器超時、記憶體不足或網路斷線而異常中斷，鎖定就會殘留在資料庫中，導致你之後不管怎麼嘗試都無法執行任何更新。

這個問題在各種 WordPress 網站上都可能發生，不論你使用的是共享主機、VPS 還是 Kinsta 這類高階託管主機。差別在於，好的主機環境因為資源充足、執行時間限制寬鬆，遇到更新卡住的機率相對較低。如果想要瞭解更多關於 WordPress 本身的運作原理，可以參考我們的 WordPress 完整介紹，裡面對 WordPress 的核心架構有更深入的說明。

這個錯誤跟 WordPress 的「簡短維護模式（Briefly Unavailable for Scheduled Maintenance）」有關聯但不完全相同。維護模式是 WordPress 在更新過程中暫時讓前台顯示維護頁面的機制，而「Another Update in Process」則是針對後台更新操作的鎖定。不過兩者有時候會同時出現，因為背後的觸發原因經常是同一件事：更新程序沒有正常完成。接下來我們就來深入瞭解這個鎖定機制的運作原理，以及為什麼它會卡住。

為什麼會出現「Another Update in Process」錯誤？根本原因解析

要真正理解這個錯誤，需要先認識 WordPress 的更新鎖定機制是怎麼運作的。WordPress 從 4.0 版本開始，在核心更新的流程中引入了一個資料庫層級的鎖定。每當 WordPress 準備執行核心更新時，它會在 wp_options 資料表中插入一筆名為 core_updater.lock 的選項記錄。這筆記錄就像是一個「正在更新中，請勿打擾」的告示牌，告訴系統不要啟動任何新的更新程序。

當更新順利完成後，WordPress 會自動從資料庫中刪除這筆鎖定記錄，讓系統恢復正常狀態。在正常流程中，這個過程通常只需要幾秒到幾分鐘的時間。但如果更新在中途出了問題，比如說下載更新檔時斷線、解壓縮時空間不足、或者是複製檔案時被主機的執行時間限制強制中斷，那麼 core_updater.lock 這筆記錄就會一直留在資料庫中，不會被自動清除。

根據實際維護 WordPress 網站的經驗，有五個最常見導致更新鎖定殘留的原因：

• 主機執行時間超時：很多共享主機的 max_execution_time 設定只有 30 或 60 秒，WordPress 核心更新如果檔案較大，可能在下載和解壓的過程中就超過了這個限制。好的主機服務如 Bluehost 通常會提供更充裕的執行時間設定。如果不確定自己的主機品質，可以參考我們整理的WordPress 主機推薦懶人包。
• PHP 記憶體不足：更新過程需要讀取和寫入大量檔案，如果 memory_limit 設定太低（比如只有 32MB 或 64MB），更新程序可能在處理到一半時因為記憶體耗盡而崩潰。建議至少設定為 256MB。
• 外掛衝突：某些外掛可能會攔截或修改 WordPress 的更新流程，例如安全外掛、快取外掛或 URL 重寫外掛。這類衝突可能導致更新程序在非預期的步驟中斷。我們在WordPress 快取外掛推薦一文中也提過，某些快取機制確實會干擾更新流程。
• 網路連線不穩定：WordPress 需要從官方伺服器下載更新檔案，如果你的主機對外連線不穩定或被防火牆擋住，下載中斷就會導致更新失敗。
• 檔案系統權限錯誤：如果 WordPress 沒有足夠的權限寫入 wp-content/upgrade/ 目錄或覆蓋核心檔案，更新也會在中途失敗。

除了上述原因之外，最常見的觸發場景其實是「自動更新與手動更新的衝突」。WordPress 從 3.7 版本開始支援背景自動更新，系統會透過 wp-cron 排程定期檢查並執行小幅度的安全更新。如果你剛好在自動更新正在背景執行的時候手動點了「立即更新」，兩個更新程序就會產生衝突，觸發「Another Update in Process」的鎖定提示。

值得一提的是，wp_options 資料表是 WordPress 存放各種系統設定的核心資料表。如果你之前遇過WordPress 建立資料庫連線錯誤的問題，其實也是跟這個資料表所在的資料庫有關。理解這個資料表的結構，對排查各種 WordPress 問題都很有幫助。

搞懂了背後的原因之後，接下來就是重點：如何把這個頑固的鎖定給清除掉。下面我們提供五種不同的修復方法，從最簡單到最進階，你可以根據自己的技術水平和主機環境選擇最適合的方式。

方法一：透過 functions.php 刪除更新鎖定（最快速推薦）

這是我個人最常推薦給有一定 WordPress 操作經驗的使用者的方法，因為它不需要安裝任何額外的外掛，也不需要登入主機控制台或資料庫管理工具。整個操作可以在 WordPress 後台直接完成，通常 3 分鐘之內就能搞定。

操作步驟

第一步：登入 WordPress 後台，在左側選單中找到「外觀 > 佈景主題編輯器」（如果你使用的是英文後台，就是 Appearance > Theme Editor）。進入後，在右側的檔案列表中找到並點擊「Theme Functions」（functions.php）。

如果你的 WordPress 版本較新，後台可能會顯示一個編輯警告提示，告訴你直接編輯佈景主題檔案可能有風險。不用太擔心，因為我們只是暫時加入兩行程式碼，用完就會移除。

第二步：在 functions.php 檔案的內容區域中，在 <?php 標籤的下一行，貼上以下兩行程式碼：

global $wpdb;
$wpdb->query("DELETE FROM wp_options WHERE option_name = 'core_updater.lock'");

第三步：點擊頁面下方的「更新檔案」按鈕儲存。儲存成功的瞬間，這段程式碼就會執行，把資料庫中的 core_updater.lock 記錄刪除掉。也就是說，鎖定在你按下儲存的那一刻就已經被解除了。

第四步（重要！）：鎖定解除之後，你必須把剛才加入的兩行程式碼刪除，然後再次點擊「更新檔案」。這一步千萬不能省略，因為如果你把這段刪除程式碼留在 functions.php 中，每次有人載入你的網站頁面時都會執行這段查詢，雖然不會造成嚴重問題，但會產生不必要的資料庫負載，長期下來對網站速度會有影響。

注意事項

• 資料表前綴：上面的程式碼預設使用 wp_ 作為資料表前綴。如果你在安裝 WordPress 時有修改過前綴（比如改成了 wp_abc_），請將程式碼中的 wp_options 替換成你實際的資料表名稱。你可以在 wp-config.php 檔案中的 $table_prefix 變數找到正確的前綴。
• 子主題優先：如果你有使用子主題，建議在子主題的 functions.php 中操作，這樣即使出問題也不會影響到父主題的原始檔案。挑選佈景主題時可以參考我們的WordPress 主題挑選指南。
• 操作時機：建議在網站流量較低的時段操作，雖然這個操作風險很低，但養成好習慣總是比較保險。

完成這四個步驟後，你就可以回到 WordPress 的更新頁面，正常執行所有更新操作了。如果這個方法因為某些原因無法使用（比如佈景主題編輯器被主機商停用），可以繼續嘗試下面的其他方法。如果你在操作過程中遇到任何權限相關的問題，也可以參考我們關於優化 WordPress 網站速度的教學，裡面有提到一些常見的主機設定調整方式。

方法二：安裝 Fix Another Update In Progress 外掛（免寫程式碼）

如果你對修改程式碼有任何顧慮，或者你的 WordPress 後台因為主機安全設定而無法使用佈景主題編輯器，那麼使用專門的外掛來修復就是最安全的選擇。這個方法完全不需要接觸任何程式碼，只需要幾次點擊就能完成修復。就跟處理 WordPress 自動儲存功能的方式類似，很多時候安裝對的外掛就能快速解決問題。

安裝與操作流程

第一步：登入 WordPress 後台，前往「外掛 > 安裝外掛」，在右上角的搜尋欄位中輸入「Fix Another Update In Progress」。在搜尋結果中找到同名的外掛，點擊「立即安裝」，安裝完成後點擊「啟用」。

第二步：啟用後，在 WordPress 後台左側選單中找到「設定 > Fix Another Update In Progress」進入外掛的設定頁面。如果你的網站目前確實存在更新鎖定的問題，頁面上會顯示一段文字：「WordPress Update is locked. Click the button below to fix it.」，下方會有一個標示為「Fix WordPress Update Lock」的按鈕。

第三步：點擊「Fix WordPress Update Lock」按鈕。外掛會自動幫你刪除資料庫中的鎖定記錄，處理完成後頁面會顯示成功訊息，告訴你「Update lock issue」已經被解決。

第四步：修復完成後，回到「外掛 > 已安裝外掛」頁面，把 Fix Another Update In Progress 外掛停用並刪除。這個外掛的用途就是一次性修復，不需要長期保留在網站上。保留不必要的外掛反而可能拖慢網站速度，這一點我們在WordPress SEO 外掛推薦的文章中也提過，精簡外掛數量是維護網站效能的基本原則。

這個方法的優缺點

最大的優點就是零門檻，完全不用擔心改錯程式碼。不過要注意的是，如果你的 WordPress 後台連更新頁面都進不去（比如整個後台都被鎖住了），那你可能沒辦法安裝這個外掛，這時就需要改用後面提到的 phpMyAdmin 或 FTP 方法。

順帶一提，養成定期備份的習慣比學會修復錯誤更重要。使用 UpdraftPlus 備份外掛可以在任何操作前先做一個完整的網站快照，這樣即使操作過程中出問題，也能快速恢復到原本的狀態。

方法三：透過 phpMyAdmin 直接操作資料庫（進階用戶適用）

phpMyAdmin 是絕大多數主機控制台都會提供的資料庫管理工具。透過它，你可以直接對 WordPress 的資料庫進行操作，不需要經過 WordPress 後台。這個方法的好處是即使 WordPress 後台完全無法操作，你依然可以修復鎖定問題。不少優質的 WordPress 主機服務（包括 SiteGround、CloudAccess 等）都在控制台中內建了 phpMyAdmin。

操作前的準備

在開始之前，強烈建議你先備份整個資料庫。雖然我們只是要刪除一筆記錄，但養成操作前備份的習慣可以讓你安心很多。如果在操作過程中不小心刪錯了東西，有備份就能立即恢復。你的主機控制台通常會有「備份」或「Backup」的功能，點一下就能匯出完整的資料庫備份檔。

詳細操作步驟

第一步：進入 phpMyAdmin。登入你的主機控制台（cPanel、Plesk、DirectAdmin 或是 SiteGround 等主機的自訂面板），找到「phpMyAdmin」或「資料庫管理」的圖示，點擊進入。

第二步：選擇資料庫。在 phpMyAdmin 左側的資料庫列表中，找到你的 WordPress 網站所使用的資料庫並點擊。如果你有多個資料庫不確定哪個是 WordPress 的，可以打開你的 wp-config.php 檔案，找到 DB_NAME 那一行，後面的值就是你的資料庫名稱。如果你之前遇過 WordPress 建立資料庫連線錯誤的問題，那你應該對這個檔案不陌生。也可以透過WordPress 市佔率一文瞭解更多 WordPress 的背景資訊。

第三步：找到 wp_options 資料表。展開資料庫後，你會看到很多資料表。找到名稱類似 wp_options 的資料表並點擊。注意，如果你的 WordPress 安裝時有自訂資料表前綴，這個名稱前面的 wp_ 可能會是其他字串，比如 wp_abc_options 或 mysite_options。

第四步：搜尋鎖定記錄。在 wp_options 資料表的頁面上方，點擊「搜尋」標籤。在搜尋條件中，將 option_name 欄位的條件設為「core_updater.lock」，運算子選擇「等於」或「LIKE」。點擊「執行」。

第五步：刪除鎖定記錄。如果搜尋結果中有找到 option_name 為 core_updater.lock 的記錄，直接勾選該筆記錄並點擊「刪除」按鈕。phpMyAdmin 會跳出確認提示，點擊「確定」即可。

第六步：確認刪除成功。再次搜尋 core_updater.lock，確認已經找不到任何結果，表示鎖定已成功解除。回到 WordPress 後台的更新頁面，你應該就能正常執行更新了。

小提醒

在 phpMyAdmin 中操作時，請只刪除 core_updater.lock 這一筆記錄就好。不要動到其他任何資料，尤其是你不確定用途的選項。WordPress 的 wp_options 資料表存放了網站的大量設定值，誤刪可能導致整個網站出問題。

如果你不習慣用 phpMyAdmin 的介面，也可以考慮使用 Filester 檔案管理外掛，它讓你直接在 WordPress 後台管理伺服器上的檔案，不需要額外開啟 FTP 工具。對於資料庫操作來說，phpMyAdmin 還是最直接的工具。

方法四：透過 FTP/SFTP 手動處理（主機層級解法）

有時候「Another Update in Process」的問題不只是資料庫鎖定，還可能伴隨著 WordPress 維護模式卡住的狀況。WordPress 在更新過程中會在根目錄下建立一個名為 .maintenance 的隱藏檔案，用來暫時讓前台顯示維護頁面。正常情況下，更新完成後這個檔案會被自動刪除。但如果更新中途失敗，.maintenance 檔案可能會殘留在伺服器上，導致前台一直顯示「正在進行定期維護，請一分鐘後再試」。

使用 FTP/SFTP 工具操作

第一步：使用 FTP 或 SFTP 工具（例如 FileZilla）連線到你的主機伺服器。連線資訊通常可以在主機商提供的歡迎信件中找到，或者在你的主機控制台中查看 FTP 帳號設定。

第二步：連線成功後，進入 WordPress 網站的根目錄（也就是 wp-config.php 和 wp-settings.php 所在的目錄）。由於 .maintenance 是一個以句號開頭的隱藏檔案，你需要在 FTP 工具中開啟顯示隱藏檔案的選項才能看到它。在 FileZilla 中，可以從選單選擇「伺服器 > 強制顯示隱藏檔案」。

第三步：如果看到了 .maintenance 檔案，直接把它刪除或重新命名（例如改成 .maintenance.bak）。刪除後，WordPress 前台應該會立即恢復正常顯示。

第四步：接著檢查 wp-content/upgrade/ 目錄。這個目錄是 WordPress 用來存放更新過程中的暫存檔案的位置。如果有殘留的資料夾（名稱通常類似 wordpress-6.x.tmp 或 upgrade-temp-backup），可以把它們刪除。這些暫存檔案有時候也會干擾後續的更新流程。

不用 FTP 的替代方案

如果你沒有 FTP 的登入資訊，或者不熟悉 FTP 工具的操作，有一個更方便的替代方案：安裝 Filester 檔案管理外掛。這個外掛讓你直接在 WordPress 後台就能瀏覽和管理伺服器上的所有檔案，功能等同於一個網頁版的 FTP 工具。安裝後進入外掛頁面，找到 WordPress 根目錄下的 .maintenance 檔案，直接刪除即可。

如果你是在WordPress 測試網站上練習操作，建議先用測試環境熟悉整個流程，確認沒問題後再到正式網站上執行。在正式環境中進行任何檔案操作之前，也請先確認你有最新的完整備份。如果你使用的是 WP Umbrella 等網站監測工具，也可以在操作前先確認網站的運行狀態。

方法五：使用 WP-CLI 命令列工具（開發者首選）

如果你是 WordPress 開發者或系統管理員，習慣用命令列管理網站，那 WP-CLI 絕對是你修復這個問題最順手的方式。WP-CLI 是 WordPress 官方維護的命令列介面工具，可以讓你用終端機指令完成大部分 WordPress 後台能做的事情，甚至更多。

修復指令

透過 SSH 連線到你的主機後，進入 WordPress 根目錄，執行以下指令：

wp option delete core_updater.lock

就這麼一行。執行後如果看到「Success: Deleted ‘core_updater.lock’ option.」的訊息，表示鎖定已經成功移除。如果看到「Error: Could not delete ‘core_updater.lock’ option. Does it exist?」的提示，可能是鎖定已經不存在了（可能已經自動解除，或者你之前已經處理過了）。

解除鎖定後，你可以直接在同一個終端機中執行核心更新：

wp core update

常見問題

主機是否支援 WP-CLI？目前市面上主流的 WordPress 主機商大部分都預裝了 WP-CLI，包括 Bluehost、Kinsta、A2 Hosting 等。如果不確定你的主機是否支援，可以 SSH 連線後執行 wp --info，如果能看到版本資訊就表示支援。像 RunCloud 和 ServerPilot 這類 VPS 管理平台也都有內建 WP-CLI。

資料表前綴不是預設的 wp_ 怎麼辦？WP-CLI 會自動讀取 wp-config.php 中的資料表前綴設定，所以一般情況下不需要額外處理。但如果你的 wp-config.php 位置不在標準路徑上，可能需要用 --path 參數指定 WordPress 的安裝路徑。

WP-CLI 的操作效率遠高於網頁介面，對於管理多個 WordPress 網站的開發者來說是必備工具。不過如果你只有一兩個網站而且不熟悉終端機操作，前面的幾種方法會更適合你。

5 種修復方法比較：哪種最適合你？

看完了五種修復方法，你可能會想知道哪一種最適合自己的情況。下面這張比較表可以幫你快速做決定：

方法	難度	所需時間	風險等級	適用對象
方法一：functions.php	中低	3 分鐘	低	有基本 WordPress 操作經驗的使用者
方法二：Fix Another Update In Progress 外掛	低	2 分鐘	極低	完全新手，不想碰程式碼
方法三：phpMyAdmin	中	5 分鐘	中	熟悉主機控制台和資料庫操作的使用者
方法四：FTP/SFTP	中	5-10 分鐘	中低	有 FTP 經驗，需同時處理 .maintenance 檔案
方法五：WP-CLI	中高	1 分鐘	低	開發者或系統管理員

從實用角度來說，我的建議是這樣的：

• 如果你是 WordPress 新手，直接用方法二（外掛），全程圖形化操作，完全不需要擔心改錯東西。
• 如果你對 WordPress 後台操作有一定的熟悉度，方法一（functions.php）是最快最直接的，而且不需要安裝額外的外掛。
• 如果你有技術背景，方法三（phpMyAdmin）和方法五（WP-CLI）可以讓你更精確地確認和控制鎖定狀態。
• 如果問題伴隨前台維護模式卡住，方法四（FTP/SFTP）可以一併處理 .maintenance 檔案的問題。

不論你選擇哪一種方法，操作之前都建議先做一個完整的網站備份。這個好習慣可以在任何意外發生時讓你快速回到安全的狀態。如果你想找一個資源充足、更新過程穩定的主機環境來減少這類問題的發生頻率，可以參考我們整理的 WordPress 主機推薦，裡面有針對不同需求和預算的完整評比。考慮到更新穩定性，像是 Bluehost WordPress 一鍵安裝教學中展示的那種針對 WordPress 最佳化的主機環境，通常能減少這類更新問題的發生。

如何預防 WordPress 更新卡住？6 項最佳實踐

修復問題只是治標，真正重要的是減少這個問題發生的機率。根據多年維護 WordPress 網站的實際經驗，以下六個最佳實踐可以大幅降低更新卡住的風險：

1. 更新前一定要完整備份

這條規則沒有例外。不論你更新的是核心版本、外掛還是佈景主題，每次更新前都應該做一個包含檔案和資料庫的完整備份。UpdraftPlus 是一款免費且好用的 WordPress 備份外掛，可以一鍵備份整個網站並上傳到雲端空間。有了備份，就算更新過程中出現任何問題，你都可以在幾分鐘內恢復到更新前的狀態。這跟WP Rocket 等快取外掛一樣，是 WordPress 網站必備的工具之一。

2. 執行重大更新前停用所有外掛

WordPress 的核心更新牽涉到大量檔案的替換和資料庫結構的調整。如果在這個過程中有外掛嘗試攔截或修改更新流程，很容易造成衝突。建議在執行 WordPress 核心大版本更新（比如從 6.4 升到 6.5）之前，先到「外掛」頁面把所有外掛停用，更新完成後再逐一啟用並測試。這樣可以快速定位到底是哪個外掛造成了衝突。如果你使用的是 WooCommerce 等功能複雜的外掛，更建議在測試環境中先進行更新測試。

3. 確認主機資源充足

在 WordPress 後台的「工具 > 網站健康 > 資訊」頁面中，你可以查看目前伺服器的 PHP 設定。重點確認兩個數值：memory_limit 建議至少 256MB，max_execution_time 建議至少 300 秒。如果這兩個值設定得太低，更新過程很容易因為資源不足而中斷。這些設定通常可以在 php.ini 或 .htaccess 中修改，但部分共享主機可能不允許自行調整，這時就需要聯繫主機商協助。

4. 避免在自動更新排程時手動操作

WordPress 的自動更新是透過 wp-cron 排程系統來執行的。預設情況下，WordPress 會每天檢查兩次是否有新的核心更新。如果你在手動更新之前發現系統似乎正在背景做些什麼，可以先等個幾分鐘再操作。避免同時觸發兩個更新程序，是預防鎖定衝突最直接的方式。

5. 選擇穩定可靠的主機服務

主機環境的穩定性對 WordPress 更新能否順利完成有直接影響。一個資源充足、配置合理的主機可以避免大部分因為超時或記憶體不足導致的更新中斷。Bluehost 是 WordPress 官方推薦的主機之一，提供了針對 WordPress 最佳化的環境。如果你的網站流量較高或有更高的效能需求，Kinsta 的託管式 WordPress 主機提供了 Google Cloud Platform 等級的基礎設施和自動更新管理機制。你也可以參考 Cloudflare CDN 教學來進一步提升網站的整體穩定性與安全性。

6. 定期更新，不要累積版本差異

跨太多版本更新是導致更新失敗的常見原因之一。如果你的 WordPress 版本落後了好幾個大版本，更新時需要處理的檔案變更和資料庫遷移量會大很多，出錯的機率自然也跟著提高。養成定期更新的習慣，每次更新都是小幅度改動，風險會低很多。這個原則不只適用於 WordPress 核心，也適用於外掛和網站安全相關的維護。

更新解除後仍無法更新？排查其他可能原因

大多數情況下，按照上面的方法清除鎖定之後，WordPress 就能恢復正常更新了。但偶爾你會遇到一個令人沮喪的情況：明明已經清除了 core_updater.lock，更新頁面還是報錯，或者更新過程再次失敗。這時候問題可能不只是單純的鎖定殘留，而是有其他更深層的原因。

維護模式卡住

前面有提到，WordPress 在更新過程中會建立 .maintenance 檔案。如果你只清除了資料庫中的鎖定但沒有刪除這個檔案，前台可能還是會顯示維護中頁面。這時候需要用 FTP 或檔案管理工具手動刪除根目錄下的 .maintenance 檔案。不確定怎麼操作的話，可以回頭看「方法四：FTP/SFTP」那一段的詳細說明。

PHP 版本不相容

每個新版本的 WordPress 都會有最低 PHP 版本需求。如果你主機上的 PHP 版本太舊，更新可能會在檢查階段就被擋下來。WordPress 6.x 系列通常需要 PHP 7.4 或更高版本。你可以在 WordPress 後台的「工具 > 網站健康」頁面中查看目前的 PHP 版本。如果版本太舊，聯繫你的主機商升級 PHP 版本，或者考慮換到一個提供新版本 PHP 的主機，像是 Hostinger 等平價主機商都提供一鍵切換 PHP 版本的功能。

檔案和目錄權限問題

WordPress 在更新過程中需要寫入檔案到多個目錄。如果檔案權限設定不正確，更新會因為無法寫入而失敗。一般來說，目錄的權限應該設為 755，檔案的權限應該設為 644。你可以透過 FTP 工具檢查 WordPress 核心目錄和 wp-content/ 目錄的權限設定。如果發現權限數值偏差很大（比如 000 或 777），需要手動修正。

外掛或佈景主題衝突

某些外掛或佈景主題可能會攔截 WordPress 的更新流程，或者佔用過多的系統資源導致更新超時。如果你懷疑是這個原因，可以嘗試停用所有外掛後再執行更新。如果停用後更新成功，再逐一啟用外掛來找出是哪一個造成衝突。有些外掛如 Disable Comments 在停用後可能需要重新設定，所以停用前的備份格外重要。

主機資源限制

如果你的網站流量較大或者主機方案資源有限，更新過程可能因為記憶體耗盡或執行時間超限而失敗。這類問題在免費或低價的共享主機上更常見。如果你經常遇到更新相關的問題，可能是時候考慮升級到更好的主機方案了。我們整理了 500 Internal Server Error、502 Bad Gateway、503 Service Unavailable、504 Gateway Timeout 等 WordPress 常見錯誤的完整修復教學，如果你遇到的問題不只是更新鎖定，可以一併參考。

如果以上排查都做過了還是無法正常更新，問題可能出在更深層的 WordPress 更新機制上，建議聯繫你的主機商技術支援團隊尋求協助。

常見問題 FAQ

Q1: 這個錯誤會導致網站資料遺失嗎？

不會。「Another Update in Process」的鎖定機制本身不會造成任何資料損壞或遺失。它只是在 wp_options 資料表中建立的一筆臨時記錄，用來防止同時執行多個更新。即使這筆記錄一直留在資料庫中，也不會影響網站前台的正常運作或已有的內容資料。它只會影響你在後台執行新更新的能力。

Q2: 不手動修復的話，鎖定多久會自動解除？

WordPress 的更新鎖定有一個 15 分鐘的有效期限。理論上，即使更新失敗，15 分鐘後鎖定也應該過期失效。但在實際使用中，由於 wp-cron 排程的觸發方式（需要有人造訪網站才會執行），鎖定過期的清理動作可能不會那麼即時。如果你的網站流量很低，有可能過了好幾個小時鎖定都還沒被清理掉。所以手動修復通常是最可靠的做法。

Q3: 修復後仍然看到同樣的錯誤訊息怎麼辦？

有可能的原因包括：(1) 你的瀏覽器快取了舊的後台頁面，試試強制重新整理（Ctrl+F5 或 Cmd+Shift+R）；(2) 你的 WordPress 安裝使用了非標準的資料表前綴，但修復時用的是預設的 wp_options，請確認實際的資料表名稱；(3) 除了 core_updater.lock 之外，還有其他類型的鎖定（如外掛更新鎖定 auto_updater.lock），也需要一併清除。

Q4: 免費主機更容易遇到這個問題嗎？

確實如此。免費或低價的共享主機通常有更嚴格的資源限制，包括較低的 PHP 記憶體上限、較短的執行時間限制，以及更不穩定的網路連線品質。這些限制都會增加更新過程中斷的機率，進而導致鎖定殘留。如果你的網站有一定的流量和重要性，建議選擇品質較好的主機服務。Bluehost 提供了非常親民的入門價格（每月不到 3 美元），而 Kinsta 則適合需要頂級效能的專業網站。完整的比較可以參考我們的SiteGround 主機評價和其他主機推薦文章。

Q5: 可以長期忽略這個錯誤嗎？會有什麼後果？

短期內忽略不會造成立即性的危害，但長期來看風險很大。如果你的 WordPress 無法更新，就無法獲得最新的安全修補程式，這會讓你的網站暴露在已知的安全漏洞之下。駭客經常利用舊版本 WordPress 的已知漏洞來入侵網站。過舊的 WordPress 版本也同樣可能與新版外掛和佈景主題不相容，逐漸影響網站的正常功能。我們在 WordPress 安全防護相關文章中有更詳細的說明。

Q6: 自動更新和手動更新，哪個更容易觸發此錯誤？

單獨使用其中一種更新方式通常不會有問題。最容易觸發鎖定衝突的場景是「兩者同時發生」。比如 WordPress 正在背景執行自動安全更新，而你剛好在同一時間手動點擊了更新按鈕。要避免這種情況，可以在手動更新前先到「設定 > 一般」確認一下目前是否有正在進行的背景任務。

Q7: 如何確認鎖定已成功解除？

最直接的方式是到 phpMyAdmin 中查詢 wp_options 資料表，搜尋 option_name = 'core_updater.lock'。如果找不到任何結果，就表示鎖定已經成功移除。另一個更簡單的驗證方式是直接回到 WordPress 後台的更新頁面，嘗試點擊「重新安裝」或「立即更新」按鈕，如果能正常執行就表示鎖定已經不在了。

Q8: 這個錯誤和 WordPress 維護模式有什麼不同？

兩者是不同的機制但經常一起出現。「Another Update in Process」是資料庫層級的鎖定，作用於後台更新頁面，阻止你啟動新的更新。而「簡短維護模式」是檔案層級的機制，作用於網站前台，透過 .maintenance 檔案讓訪客看到維護中頁面。一個更新失敗可能同時留下資料庫鎖定和 .maintenance 檔案，所以有時候你需要同時處理這兩個問題才能讓網站完全恢復正常。