2026 年走到第二季，PHP 官方主力分支已經推進到 8.5，4 月剛釋出的 PHP 8.5.6 進入穩定維運，PHP 8.4 則因為安全性更新會延續到 2028 年底，仍是多數虛擬主機商目前預設的正式版本。對照之下，PHP 7.4 早在 2022 年就結束安全性更新，8.0、8.1 也分別在 2023、2025 年退場。

實際走訪台灣中小型站台，仍有不少佈景主題、購物車外掛、自寫的 functions.php 卡在 7.4 至 8.0 之間。維持舊版表面看是「能跑就好」的低風險選擇，但 WordPress 官方已宣布在 7.0 版（預計 2026 年 4 月）將最低支援版本拉到 PHP 7.4，主流外掛跟進的速度只會更快。一旦核心、外掛、主題三邊的最低需求往上漂，舊版站台會在某次自動更新後突然白屏，那種半夜被警報叫醒的場面，比事前花一個下午做相容性盤點昂貴得多。

這份 PHP 版本升級 WordPress 的相容性檢查指南，目的不在催促立刻跳到最新版，而是把升級前該確認的事情列清楚，讓站長能在測試環境先把問題找完，主站再用最短的維護視窗切過去。

還跑在 PHP 7.4 的站台 2026 年要面對什麼

把版號當成單純的數字會錯估風險。PHP 從 7.4 到 8.x 之間，並不是「跑得更快」這麼單純的差異，而是整個型別系統、錯誤處理、屬性宣告規則的世代差。

效能層面，PHP 8.3 相對 7.4 在典型 WordPress 工作負載下大約有 15% 至 30% 的請求耗時下降，啟用 JIT 後的密集運算場景差距會再拉開。對流量上千的部落格或商品數破千的 WooCommerce 站，這個差距等於同樣硬體可以多撐一倍流量，或反過來能把主機規格降一級。

更急迫的是安全性更新。7.4 結束維護後，後續被回報的記憶體釋放、反序列化漏洞官方已不會回填修正，主機商雖然有些會自掏腰包做 backport，但覆蓋率與時效都不如官方。一旦碰上類似 2024 年那波 phar 反序列化的廣域掃描，舊版站台幾乎是裸奔。

外掛生態也在跟著拋棄舊版。WooCommerce、Yoast SEO、Wordfence、Elementor 等龍頭外掛在 2025 至 2026 年陸續把最低 PHP 需求拉到 8.1 或 8.2，站台版本若不跟上，自動更新會在某個版次後直接跳過該外掛的安全修補。版次落後三、四個小版本後，外掛市集的支援工單也會請站長先升級 PHP 再回頭談。

升級前要跑過的三套相容性檢查工具

在按下主機面板的 PHP 切換按鈕之前，先用工具把站台現有程式碼掃過一輪。三套工具職責不同，缺一不可，建議依序跑完再評估升級時程。

• PHP Compatibility Checker（WP 外掛版）：WP Engine 維護的靜態掃描外掛，能針對指定的目標 PHP 版本（8.1、8.2、8.3、8.4）掃描所有外掛與主題程式碼，列出已淘汰函式、語法錯誤、相容性警告。掃描結果分 ERROR 與 WARNING 兩級，ERROR 必須處理，WARNING 排入優先序。
• WP-CLI 配合 PHPCompatibility 規則集：對於有 SSH 存取權的站台，從命令列跑 vendor/bin/phpcs --standard=PHPCompatibilityWP --runtime-set testVersion 8.3 比 GUI 版精確，並能對指定目錄遞迴掃描，輸出可進 CI 流程的 JSON 報告，適合多人協作或正在做主題客製化的站。
• Query Monitor：靜態掃描看不到的執行期問題交給這套外掛。安裝後在管理列開啟「PHP Errors」面板，把首頁、文章頁、購物車頁、結帳頁、後台主要管理頁逐一點過一輪，所有 Deprecated／Notice／Warning 都會被攔下，重點看「Creation of dynamic property」「each() is deprecated」「Implicit conversion」這三類訊息。

三套工具的執行順序，建議讓靜態掃描走在前頭定位高風險檔案，接著開 Query Monitor 補執行期才會觸發的問題，再拿 WP-CLI 在測試站做完整回歸。每一輪掃完都先存一份 ERROR／WARNING 清單，後續處理才不會有遺漏。

functions.php 與舊版主題常壞掉的語法

掃描清單裡會出現大量重複型錯誤，多數源頭都在佈景主題與少數老外掛的 functions.php。下面這幾類是 2026 年仍在踩的高頻問題，看到就直接改寫。

• create_function 整段被移除：PHP 7.2 起列為淘汰，8.0 完全移除。常見於 2017 年前的主題用來動態註冊 widget、shortcode、filter callback，必須改寫成匿名函式（closure）或正常的命名函式。
• each 函式 8.0 起消失：典型寫法是 while (list($k, $v) = each($array))，需改用 foreach 重寫，邏輯等價但要小心原本依賴內部指標位置的程式段。
• 動態屬性 8.2 起發出 Deprecated 警告，9.0 起變致命錯誤：類別未在宣告中列出的屬性如果在執行期被設值，會被攔。解法可依場景選擇，例如在類別上方標 #[AllowDynamicProperties] 屬性、明確宣告該屬性、或實作 __set 魔術方法。
• array_key_exists 對物件丟錯：8.1 起對物件呼叫此函式會發 Deprecated，9.0 會直接報錯，改用 property_exists() 或 isset()。
• strip_tags 收 null 報錯：8.1 起內部函式對 null 傳入禁用，常見於從 get_post_meta 撈值未做 null 檢查就丟進 strip_tags，補一層 ?? '' 預設值即可。
• 隱含浮點轉整數警告：把 (int) 強制轉型補上去就解決，但量大時要小心改錯資料型別。

處理順序的判準很單純，依「會不會白屏」分兩堆。create_function、each、array_key_exists 對物件這類在新版會直接拋 fatal error，列為升級前必修。動態屬性、strip_tags null、隱式轉型在 8.3 仍只是 Deprecated 警告，可以排在升級後第一週內補完，但不能拖到 PHP 9.0，否則同樣會變致命錯誤。

從測試站到主站的三階段推進節奏

掃描跟改寫做完，剩下的就是怎麼把升級切過去。直接在主機面板按下 PHP 8.3 然後祈禱的做法已經不適合 2026 年的流量規模，下面三個階段對應實際的執行順序，每一階段都有明確的驗收條件才往下推。

測試站全量還原與升級

從主站把資料庫與 wp-content 整份匯出，還原到一個獨立網域或子網域的測試站。主機商如果有提供 staging 環境就直接複製過去，沒有的話用 All-in-One WP Migration 或 Duplicator 搬。

測試站到位後，先在原 PHP 版本下確認站台正常運作，再把測試站的 PHP 切到目標版本（建議直接跳 8.3 或 8.4，不需要逐版小跳）。切換完成後重新跑一次 Query Monitor 巡檢，把首頁、分類頁、單篇文章、搜尋、留言提交、聯絡表單送出、購物車加購、結帳付款、後台發文、後台外掛更新這 10 個動線跑過一輪，所有報錯都記錄回前一節的處理清單。

驗收條件是 Query Monitor 的 PHP Errors 面板在主要動線上不再出現 ERROR 級別訊息，Deprecated 警告數量可接受但要有清單，主站升級後再追補。

主站排程升級的時段選擇

測試站乾淨後，選一個流量低谷時段切主站。部落格站建議週二到週四的清晨 03:00 至 06:00，電商站要避開週末檔期與發薪日後的促銷波，並提前 7 天在後台公告維護時間。

切換前在主機面板開啟備份，確認備份完成後再按下 PHP 版本切換鈕。多數共享主機與雲端主機切換在 30 秒內完成，不會中斷現有連線，但要立刻打開前台用無痕視窗確認首頁、登入頁、結帳頁三個關鍵頁面，後台則確認外掛清單沒有出現「Plugin file does not exist」這類錯誤。

如果切換後 5 分鐘內前台出現白屏或 500 錯誤，第一動作是切回原版 PHP，而不是嘗試在線上除錯，回滾後重新檢視測試站漏掉的環節再規劃下一次。

升級後 24 小時的監測重點

切換成功後不要立刻關掉維護模式就走，至少留 24 小時的密集觀察期。重點看四件事，error_log 的 PHP Fatal 與 Warning 累積量、Google Search Console 的索引涵蓋範圍是否出現新的 5xx 報告、主機商提供的 PHP 工作者佔用率與記憶體使用曲線、留言與表單系統的退件率。

error_log 不要只看前端公開頁面，後台排程（wp-cron）執行的時段最容易爆出 cron callback 的相容性問題，下午與凌晨整點前後是好幾類定時任務集中觸發的時間。若發現 fatal error 集中在特定外掛，先在後台停用該外掛確認可復原，再決定是更新該外掛、找替代品還是回滾 PHP 版本。

24 小時內若觀察曲線平穩、無新的 fatal 紀錄，可以視為升級穩定，剩下的 Deprecated 警告排進兩週內的維運清單逐步補完。

升級之後仍要關注的相容盲點

PHP 版本切過去不代表事情結束。升級後的兩到四週內，幾個盲點仍需要回頭看。

主機商的 PHP 模組版本不一定跟官方同步。OPcache、APCu、ImageMagick、GD、Redis 這些常被站台依賴的擴充模組，主機商升級節奏可能落後核心 1 到 2 個小版本，遇到怪異的記憶體錯誤先回頭確認模組版本。

外掛的延後相容也常見。有些外掛在自己的 readme 標稱支援 PHP 8.3，但實際程式內仍藏著對 8.0 才有的行為依賴，這類問題在 Query Monitor 不會立刻浮現，要等到特定工作流（像是批次匯入、跨站同步）才觸發。把那些「升級後沒立刻測到」的工作流補進兩週內的回歸清單。

工具鏈本身也是一個容易被忽略的環節。撰寫主題或自有外掛的站台，本機開發環境的 PHP 版本要跟著拉齊，CI 跑的測試矩陣加入目標版本，這樣下一次跨大版本時不會又從掃描跑起。把 PHP 版本當成站台基礎建設的一部分定期校準，比每兩年驚險地切換一次健康得多。