WooCommerce 換 PHP 版本前：外掛、主題與錯誤日誌要看甚麼
PHP 版本升級不是「按一下切換」那麼簡單。版本號只是入口；真正決定網店能否運作的，還有哪一個 PHP SAPI 在跑、載入了甚麼設定與擴充、外掛與主題依賴哪些行為，以及 staging 有沒有走完真正的業務路徑。首頁打得開，甚至後台登入得到，都不足以證明結帳、付款回呼、訂單電郵與背景工作在新 runtime 下仍然正常。
本文只處理更換 PHP runtime 前的相容性與可回復性。它不重複staging 隔離、更新後功能回歸、快取排查、更新後安全訊號、還原演練或換主機後營運驗收的完整清單；那些文章分別處理隔離、更新後行為、快取、安全、還原與搬遷後營運，本篇聚焦 PHP runtime 本身。
本文不會提供「所有外掛在 PHP X 都相容」的名單。 官方平台基線、WooCommerce 核心測試範圍，與每一個外掛、主題、付款模組及自訂碼的兼容性，是三件不同的事。以下版本資料是 2026 年 11 月 1 日查核的官方頁面快照；目標版本仍要按實際依賴、供應商支援與 staging 證據決定，不能把「支援」當成永久保證。
一、先分清三層「相容」：平台、runtime、網站程式碼
第一層是平台基線。PHP 官方支援表在 2026 年 11 月 1 日列出：PHP 8.2 只提供安全修正至 2026 年 12 月 31 日；8.3 只提供安全修正至 2027 年 12 月 31 日；8.4 仍在 active support 至 2026 年 12 月 31 日、安全修正至 2028 年 12 月 31 日；8.5 在 active support 至 2027 年 12 月 31 日、安全修正至 2029 年 12 月 31 日 [1]。這些是 PHP 專案的分支支援期，不是 WordPress 或任何外掛的兼容承諾。
WordPress 官方要求頁建議 PHP 8.3 或以上 [2]。WooCommerce 現行伺服器建議同樣寫 PHP 8.3 或以上，並標示核心測試至 PHP 8.4；其版本表則列出 WooCommerce 10.8 的最低 PHP 為 7.4 [3][4]。最低要求、建議版本與實際測試範圍並不相同，不能只看其中一個數字；7.4 只是最低門檻，且已停止支援，不應被當成目標版本。
第二層是實際 runtime。同一個 PHP 8.4 版本，可以由 Apache 模組、PHP-FPM 或 CLI 執行；它們可能讀取不同的 php.ini、載入不同擴充，亦有不同資源限制。PHP 文件明言 CLI SAPI 與其他 SAPI 有差異 [5]，FPM 亦有自己的程序管理與設定 [6]。所以「伺服器支援 PHP 8.4」不等於「網站正在用 PHP 8.4 跑同一個設定」。
第三層是網站自己的程式碼。WooCommerce 核心測試過某個 PHP 版本，不代表付款外掛、頁面建構器、主題 child theme、functions.php 片段、mu-plugin 或自訂 REST endpoint 也測試過。真正的驗收命題是：「這一組固定版本與設定，在隔離 staging 能否完成所有關鍵業務路徑，而且日誌沒有未處理的新錯誤？」不是「版本號有沒有過最低門檻」。
二、先把現在跑甚麼量清楚：web/FPM 與 CLI 要分開記
在同一個 terminal 執行 php -v，看到的是 CLI 的 PHP，不是訪客請求所用的 web/FPM runtime。PHP 文件亦指出，php -v 可顯示目前執行的是 CGI 還是 CLI [5]。若你在 CLI 見到新版 PHP，但網站仍由舊 FPM pool 服務，前台不會因此自動升級；反過來，CLI 仍是舊版，也不代表 web runtime 沒有切換。
可以在受控環境用一條只輸出基本資料的 CLI 指令建立基線：
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, " | ", php_ini_loaded_file(), PHP_EOL;'php --ini 亦可列出已載入及掃描的 .ini 檔案；PHP 會按 SAPI 名稱尋找 php-SAPI.ini，再找 php.ini，亦可能掃描額外目錄 [7]。這正好說明為何 CLI 與 FPM 可以「同版本、不同設定」。不要因為一個 runtime 正常，就推定另一個相同。
web 端要用主機控制台、WooCommerce 系統狀態或 staging 專用的受控診斷方式核對，不要公開 phpinfo()。記錄以下項目，並註明量度的是 CLI 還是 web/FPM：
- 版本與設定來源：PHP 完整版本、SAPI 名稱、載入的
php.ini與額外 ini 檔。 - 資源限制：
memory_limit、max_execution_time、max_input_vars、post_max_size、upload_max_filesize。 - 錯誤與快取：
display_errors、log_errors、error_log及 OPcache 是否啟用。 - 擴充清單：已啟用的擴充。WordPress Hosting Handbook 指出，缺少 WordPress 使用的擴充時，部分功能可能退化或失去，而第三方外掛與主題亦常提出額外伺服器要求 [12]。
WooCommerce 建議 WordPress memory limit 至少 256 MB [3]。但要留意，這個數字是 WooCommerce 的伺服器建議，不是「設定 256 MB 就一定不會記憶體耗盡」的保證；產品匯入、頁面建構器與大型報告仍可能有不同需求。也不要把 .htaccess 當作萬用修改位置：它只對支援 .htaccess 的 Apache 設定有效，FPM 或 Nginx 的設定路徑可能完全不同。
三、擴充與設定：不是「版本對」就夠
擴充（extension）與設定（configuration）是 runtime 相容性最常被漏掉的一層。PHP core 有函式，但某些功能依賴另行編譯或啟用的擴充；WordPress 核心會使用多個擴充，缺少首選擴充時可能要做更多工作，最壞情況是功能消失 [12]。因此比較新舊 runtime 時，應比對整份啟用清單，而不是只看 curl、mysqli 等一兩個常見項目。
實際做法是先建立「這個站真的在用」的清單，再對照新 runtime：
- 圖片處理：
gd或imagick的實際選擇與版本。 - 上載與 MIME：
fileinfo、檔案大小限制及post_max_size。 - 國際化：
intl、mbstring及 locale 行為。 - 資料庫：
mysqli或站點實際使用的驅動。 - 壓縮、HTTP 與加密：
zip、curl、openssl。 - 快取與效能：OPcache、Redis／Memcached 客戶端；只在站點確實使用時核對。
這不是通用必備清單，也不應把某個外掛的建議清單直接套到所有網站。重點是：實際工作負載所需的擴充與設定，在目標 runtime 有支援、已啟用並通過測試。不應盲目複製所有舊模組，也不應強制 web/FPM 與 CLI 每個設定完全相同；CLI 有較長 timeout 或其他經說明的差異可以是合理的，但要逐項記錄原因與影響。
設定值亦要連同業務影響一起看。例如 max_execution_time 很短，前台瀏覽未必出事，但匯入產品、產生報告或執行排程可能失敗；max_input_vars 太低，大型選單或變體表單可能只儲存一部分；display_errors 在正式站開啟，則可能把檔案路徑、資料庫錯誤或敏感資料送進 HTML。這些都不是單純「PHP 版本」問題，但會在同一次切換中一起暴露。
四、外掛、主題與自訂碼：先盤點依賴，再談兼容
盤點應包括正常外掛、network-activated 外掛、must-use 外掛、drop-ins、child theme、主題的 functions.php、頁面建構器儲存的模板、付款／配送／訂閱模組，以及由開發者加入的 snippets。自訂碼最容易被忽略，因為它沒有一個「外掛版本」可供查詢，也可能直接呼叫舊語法、已移除函式或依賴特定擴充。
外掛標頭可以幫助收集最低要求，但不是兼容證明。WordPress Plugin Handbook 的標頭欄位包括 Requires at least（最低 WordPress 版本）及 Requires PHP（最低 PHP 版本）[11]。這些欄位是作者宣告的最低門檻；它們不保證在更高 PHP 版本、特定擴充組合或 WooCommerce 結帳流程中沒有警告、棄用訊息或行為差異。有 Requires Plugins 時，亦要核對依賴外掛是否同時啟用及版本是否相符。
實務上應把每個項目記成一行：名稱、版本、啟用狀態、來源（官方目錄／付費授權／自訂）、宣告的 PHP／WordPress 要求、最後供應商支援訊號、由誰擁有。對已停止維護、沒有相容聲明或只寫「應該可以」的項目，應先找供應商的正式支援文件或 changelog；沒有證據就不要替它背書，也不要發明一個「全站通用」的 PHP 版本建議。
PHP 8.4 與 8.5 的官方 migration guide 會列出 backward-incompatible changes 與 deprecated 行為 [13][14]。它們適合用來界定自訂碼要搜尋或測試的範圍，但不會替你判斷某個外掛是否已更新。若某個外掛必須先升級才能在目標 PHP 運作，應把「外掛版本 + PHP 版本」視為一個組合在 staging 驗證，並記錄兩者的版本配對，而不是把多個變更混在同一次切換。
五、Staging 要像目標 runtime，並隔離真付款與真電郵
只在舊 PHP 的 staging 測試，不能回答切換後會怎樣；只在一個沒有付款、沒有 SMTP、沒有背景工作的空白 WordPress 測試，也不夠。理想的 staging 應接近目標環境：相同 PHP 主／次版本、相同 SAPI（例如 FPM）、必要的相同擴充、接近的 php.ini、相同 web server／資料庫主版本、相同物件快取，以及相同外掛與主題版本。若主機商只能提供不同 patch level 或不同資料庫小版本，應把差異寫進風險紀錄，不要假裝完全相同。完整的複製與資料隔離步驟見staging 隔離清單；以下只補 PHP runtime 切換特別容易漏的對外路徑。
- 付款與背景收款：使用付款商的測試環境或測試帳戶；不要在 staging 使用正式收款設定。特別檢查訂閱、自動續期、背景付款與排程工作，避免 clone 後用正式密鑰觸發真實交易。
- PHP
wp_mail與外掛郵件路徑：WordPress 內建郵件、外掛自帶 SMTP、API 或其他寄送服務可能走不同路徑。全部要指向測試信箱或郵件捕捉服務，設定 sink 且禁止轉寄至真實收件人。 - Clone 的正式密鑰：付款、webhook、CRM、ERP、物流與分析 endpoint 的正式 secrets 不應原樣留在可執行測試的 staging；改用測試憑證，或停用並記錄。
存取限制用於限制未授權訪問，noindex 只要求搜尋引擎不要索引，並非存取控制，不會阻止伺服器向外寄信、扣款或呼叫正式 API。測試資料亦應來自受控副本，避免把真實個資帶進不受控環境。若要把 staging 資料複製回正式站，屬於資料庫還原決策，不是 PHP 回退的一部分，兩者不可混為一談。
伺服器 cron 或 CLI 工作亦要使用獨立的測試 endpoint、測試憑證與受控資料試跑，確認不會觸發正式付款、通知、CRM 或物流；不要直接在正式 cron 上試新 runtime。若工作本身沒有安全的測試模式，應先停用並記錄，而不是讓它在 staging 對外產生副作用。
切換 staging 的 PHP 版本前後，要確認承載 web/FPM 的 OPcache 已按主機文件針對該 pool 重載／重設，否則你可能仍在執行舊程式碼。只執行 CLI 的 OPcache 重設未必影響 web 進程；亦不要為此重啟共享伺服器上無關的服務。這不代表要清除所有 CDN 或所有資料庫快取，只處理與這次 runtime 切換直接相關、且有記錄的層。
六、功能驗收：由前台走到背景工作，而不是只看首頁
PHP 相容性問題不一定在首頁出現。常見表現包括外掛啟用時 fatal error、產品頁出現 deprecated warning、表單提交後空白、結帳完成但訂單狀態沒有更新、付款回呼收到 500、訂單電郵沒有產生，或排程工作卡住。驗收應以業務路徑為單位，並為每一項留下版本、時間、預期結果與實際結果。
至少要走過以下路徑；沒有使用的功能可標記為不適用，但要說明理由，不能默默當作 pass：
- 管理員登入、外掛啟用／停用、主題切換與自訂碼載入。
- 首頁、搜尋、分類、簡單產品、可變產品、庫存狀態與相關產品。
- 加入購物車、優惠券、稅務、運費、結帳欄位、付款返回頁與付款商回呼。
- 訂單建立、狀態轉換、退款、訂單備註、客戶帳戶與訂單查詢。
- 交易電郵、SMTP 紀錄、重設密碼、聯絡表單與附件上載。
- 付款商回呼、WooCommerce webhook、Action Scheduler／WP-Cron 與外部 API。
- 匯入／匯出、媒體上載、圖片尺寸、REST endpoint、頁面建構器與短代碼。
- 如站點使用 WP-CLI、cron 或 CLI 腳本，亦要分別以目標 CLI runtime 執行一次。
每一步都要同時看畫面、資料與日誌。例如付款完成頁顯示成功，不代表商店已收到並驗證付款商回呼，也不代表訂單已正確更新；WooCommerce outbound webhook 又是另一條商店送出的通知路徑。訂單顯示 processing，也不代表庫存、電郵與排程已同步。測試完成後要清理測試資料，並記錄是否會影響正式分析、客戶名單或庫存。
七、錯誤日誌：先分流警告與錯誤，再談修正
PHP 的錯誤層級不是同一種事。E_ERROR 是會停止執行的致命 runtime error；E_WARNING 是 non-fatal 的 runtime warning，腳本通常繼續；E_PARSE 是 compile-time parse error；E_DEPRECATED 則提示某段程式碼已棄用，可能在未來版本失效 [10]。把它們全部當成同一級，會令真正致命的問題淹沒在噪音中；把 warning 全部忽略，又可能錯過下一次升級才變成 fatal 的前兆。
WordPress 的 WP_DEBUG 會令錯誤、notice 與 warning 顯示出來，WP_DEBUG_LOG 可把訊息寫入 wp-content/debug.log，WP_DEBUG_DISPLAY 可控制是否在頁面顯示 [8]。官方亦明言不建議在 live site 使用這些 debug 工具，它們應在本地或 staging 使用 [8]。因此正確做法不是「正式站開 debug 看發生甚麼」，而是：
- 在 staging 開啟
WP_DEBUG與WP_DEBUG_LOG，並把WP_DEBUG_DISPLAY設為false。 - 把 log 寫到受控位置，限制只有授權人員可讀；不要放在公開可下載的
wp-content路徑。 - 先建立測試前的日誌基線，再跑功能清單，最後比較新增的檔案、行號、訊息與次數。
- 完成後關閉 debug，刪除不必要的測試 log，保留已遮罩敏感資料的證據副本。
WooCommerce 亦在 WooCommerce > Status > Logs 提供日誌，官方說明可查看 PHP fatal errors 等資訊 [9]。但它的 fatal-errors 日誌不包含 web server timeout 等所有伺服器層問題 [9]；所以仍要分開看 PHP server log、web server log 與 WooCommerce log。找不到 log 不代表沒有問題，可能只是沒有啟用、保留期已過或寫入失敗。
分流時可按以下次序：
- Fatal／parse error：先停止切換或回退 runtime，保存堆疊與檔案行號，再找是哪個外掛、主題或自訂碼。
- Warning：記錄是否影響業務路徑；關鍵路徑出現未解釋的新 warning，就是
blocked，不是pending。若只在 deprecated 程式碼出現，仍要指定擁有者與修正期限，不能長期當作背景噪音。 - Deprecated／notice：現在就評估是否影響當前流程與下一次升級；降低
error_reporting或遮蓋訊息不是修正。 - Web server／timeout：另查 web server、FPM、proxy 與主機層，不要只貼 PHP fatal log。
八、切換窗口：runtime 回退與資料庫還原不是同一件事
切換前要有一段可控制的變更窗口，並暫停會製造新訂單或新付款的活動。先保存檔案與資料庫備份、目前 PHP／外掛／主題版本、CLI 與 web runtime 的設定、擴充清單、日誌位置，以及主機商提供的回退方法。亦要指定誰有權按下回退、誰負責對帳，不能只在出事時才找負責人。
若新 runtime 出現致命錯誤，先停止切換並執行已演練的回退計劃，不要盲目自動降級。只可回到先前已驗證、且與目前 schema／資料相容的 runtime + code 組合；若同一窗口已更新外掛或主題，部分更新可能已改變 schema 或資料，不能假設降回舊外掛版本一定安全。應查閱供應商回退指示並先評估資料影響。
單純切換 PHP 版本不應被當成資料遷移，但同一窗口綁帶的程式碼更新可能帶來不可逆的 schema／資料變更。因此 runtime 回退與資料庫還原仍是兩件事：前者是恢復已驗證的執行組合，後者是回到備份時點並承擔資料落差與對帳。
資料庫還原則是另一種、影響更大的操作。只有在資料或 schema 確實受損，且沒有更安全的修復方法時才考慮。還原會把資料庫帶回備份時點，期間的新訂單、付款、庫存、會員、電郵與背景工作可能消失；因此必須先對帳付款商、庫存、通知與 webhook，並處理在途工作。不要因為一個 PHP fatal error，就直接把整個資料庫倒回舊備份。
切換後至少要做：按主機文件重載／重設該 web/FPM 進程的 OPcache、清理有記錄的應用快取、跑一次關鍵路徑、檢查新增日誌、確認商店收到並正確處理付款商回呼與訂單電郵、查看排程是否繼續。不要用 CLI 重設代替 web OPcache，也不要為此任意重啟共享伺服器。若任何關鍵項目未測、未有證據或出現 fatal，應記為 blocked；只有非關鍵項目待補才記 pending。關鍵路徑未解釋的新 warning 亦不可記 pending，而是 blocked。pending 與 blocked 都不是 pass。
換 PHP 版本前的六步順序
- 01 · 盤點 runtimeweb/FPM 與 CLI 分開記錄
版本、SAPI、載入的 ini、資源限制與擴充清單都要有證據；CLI 的結果不代表網站請求。
- 02 · 清點依賴外掛、主題、drop-ins 與自訂碼
標頭的最低要求不是兼容證明；把版本與供應商支援訊號逐項記錄。
- 03 · 同構 staging接近目標 PHP、設定與擴充
付款、電郵、webhook 與 CRM 要隔離；不要用正式收款或向顧客發信。
- 04 · 功能驗收由產品頁走到背景工作
購物車、結帳、付款返回頁與回呼、訂單、退款、電郵、排程、上載與 REST 都要有實際結果。
- 05 · 日誌分流warning、deprecated、notice 與 fatal
先有基線再比較新增訊息；關鍵新 warning＝blocked。debug 只可在受控 staging 使用，正式站不可公開。
- 06 · 切換與回退先暫停新交易，再決定 pass／pending／blocked
只回到已驗證且兼容目前 schema 的 runtime + code；資料庫還原可能失去新訂單，必須另行對帳。
記住：PHP 版本對，不等於設定、擴充與外掛都對；首頁開得到，不等於結帳與排程已驗；關閉 warning 顯示，不等於問題消失。判定：pass＝證據完整；pending＝待補；blocked＝關鍵未驗／失敗，不可當 pass。
下載完整 SVG 流程圖九、用一張表決定 pass、pending 或 blocked
以下每一列都要有預期結果、實際結果、證據位置、時間與負責人。pass 只限證據完整且符合預期；pending 是未完成但有明確下一步；blocked 是關鍵路徑未測、失敗或證據不足。blocked／pending 不可當 pass：
| 範圍 | 要核對 | 可接納證據 | 判定 |
|---|---|---|---|
| Web runtime | 實際 SAPI、完整 PHP 版本、載入的 ini、資源限制、擴充 | 主機控制台或 Woo 系統狀態、受控 staging 診斷、版本與設定截圖 [6][7] | 只看 CLI 或只看版本號：blocked；web 與 CLI 均記錄：pass |
| 外掛／主題 | 啟用清單、版本、依賴、宣告要求、自訂碼 | 逐項清單、供應商支援文件／changelog、staging 測試結果 [11] | 以核心測試範圍代替外掛保證：blocked；逐項有證據：pass |
| Staging | 同構 runtime、隔離付款／電郵／webhook、存取限制 | 環境差異表、測試端點設定、郵件捕捉紀錄、存取控制設定 | 用正式收款或真顧客電郵：blocked；隔離完成：pass |
| 功能 | 產品、購物車、結帳、付款返回頁與回呼、訂單、退款、電郵、排程、上載、REST | 測試步驟、實際結果、訂單／日誌／郵件樣本及清理紀錄 | 只測首頁：blocked；關鍵路徑完成：pass |
| 日誌 | fatal、parse、warning、deprecated、notice 的新增與來源 | 測試前後日誌、檔案／行號、次數、已遮罩副本、WooCommerce fatal log [8][9] | 正式站開頁面 debug、忽略新 fatal 或關鍵路徑有未解釋新 warning：blocked；分流及有負責人：pass |
| 切換／回退 | 備份、回退方法、維護窗口、runtime 與 DB 還原界線、對帳 | 版本紀錄、切換清單、回退演練、付款／庫存／電郵對帳 | 把 DB 還原當成 PHP 回退：blocked；界線與負責人清楚：pass |
若 PHP 版本已停止支援，長期停留在舊版本身亦是風險；但這不代表可以跳過相容性測試，直接切到最新版本。應先確認供應商支援的版本範圍，將必要的外掛／主題更新與 PHP 切換組成可測試的組合，再安排窗口。本文不提供固定升級時數、成功率或「保證不中斷」承諾。
常見問題
PHP 8.4 是否就是 WooCommerce 的通用建議版本？
不能這樣概括。WordPress 建議 PHP 8.3 或以上；WooCommerce 現行文件建議 8.3 或以上並標示核心測試至 8.4 [2][3]。你的付款、主題、自訂碼與主機設定仍需逐項在 staging 驗證。
php -v 顯示新版本，為何網站仍然出錯？
php -v 是 CLI 的結果，網站請求可能由另一個 FPM pool 或 Apache 模組處理，並讀取不同的 php.ini 與擴充 [5][6]。要分別記錄 CLI 與 web runtime。
外掛標頭寫了 Requires PHP，是否代表一定相容？
不代表。該欄位是最低 PHP 版本要求 [11]；它不證明在更高版本、其他擴充或完整結帳流程中沒有警告或行為差異。
可否在正式站開啟 WP_DEBUG 找問題？
不建議。WordPress 官方說明 debug 工具應在本地或 staging 使用 [8]。若要記錄，應在受控環境使用 WP_DEBUG_LOG、關閉 WP_DEBUG_DISPLAY，並限制日誌存取。
出現 warning 但結帳成功，是否可以繼續上線？
不一定。warning 是非致命的 runtime 訊息，但可能指向即將失效的程式碼或只在特定路徑出現的問題 [10]。應記錄來源、影響範圍與負責人；若關鍵路徑有未解釋的新 warning，必須記為 blocked。
切換失敗時，回復 PHP 版本是否等於還原資料庫？
不是。runtime 回退只應回到先前已驗證、且與目前 schema／資料相容的 runtime + code 組合；若同窗口已更新外掛或主題，不能假設降級安全。資料庫還原則會把資料帶回備份時點，可能失去新訂單與付款紀錄，必須另行對帳。
資料來源
換版本之前，先把證據留齊
Managed-WP.™ PRO 提供 WordPress 專業代管服務。若你正整理 PHP runtime、外掛依賴、staging 驗收與錯誤日誌紀錄，可先按實際環境、版本與團隊權限確認支援範圍。
聯絡 Managed-WP.™ PRO若你需要按實際主機、PHP runtime 與外掛組合整理切換前驗收紀錄，可聯絡 Managed-WP.™ PRO。
編輯說明：本文由 Managed-WP.™ PRO 編輯團隊根據上述官方文件整理。標示為實務建議的內容不是 WordPress、WooCommerce、PHP 或主機商的保證；版本、介面、支援範圍與功能可能變更，請以實際環境及最新官方文件為準。