主機控制台裡有一個設定，很多站長裝好 WordPress 之後就再也沒動過——主機 PHP 版本設定。它不像外掛更新有小紅點提醒，也不像主題換皮容易察覺，但它對網站能否正常運作、執行效能、以及資安防護的影響程度，遠超多數人的預期。
2026 年初，WordPress 官方正式宣告計劃在 7.0 版本起放棄對 PHP 7.2 與 7.3 的支援；與此同時，PHP 8.1 已於 2025 年 12 月底正式終止維護。對於還停在舊版 PHP 的站長而言，這不只是版號數字的差距，而是網站每天都在一個沒有安全更新的環境裡持續運作。
PHP 版本號背後的支援生命週期
PHP 官方對每個大版本提供兩年主動支援（含功能更新與錯誤修復），之後再給一年純安全修補，總計三年生命週期。到期後，這個版本的所有已知漏洞都不再有官方修補，任何利用這些漏洞的攻擊都會直接穿透。
PHP 7.4 是 2022 年 11 月走到盡頭的版本，距今已超過三年未獲任何安全更新。主機商通常不會強制移除舊版，所以仍有相當比例的 WordPress 站點仍在 7.4 環境運作，等於把三年份的已知漏洞全部敞開。PHP 8.1 則於 2025 年 12 月 31 日正式到期，生命週期結束的時間點離現在更近，部分站長可能還沒意識到狀態已轉換。
目前處於主動支援或安全維護期的版本，是 PHP 8.2（安全維護至 2026 年 12 月）、PHP 8.3（安全維護至 2027 年 12 月），以及 PHP 8.4（主動支援至 2026 年 12 月，安全維護延至 2028 年 12 月）。WordPress 官方推薦版本在 2026 年已明確指向 PHP 8.3 或 8.4，其中 8.4 因為安全維護期最長，成為新建站或重新評估環境時的首選。
各版本對 WordPress 核心與外掛的實際影響
理解版號的生命週期只是第一層，更實際的問題是每個版本對 WordPress 的相容程度與效能差距。下表整理目前最常被討論的四個版本，對比角度包括官方支援狀態、WordPress 核心相容性、外掛生態成熟度，以及效能基準。
| 比較項目 | PHP 7.4 | PHP 8.1 | PHP 8.2 / 8.3 | PHP 8.4 |
|---|---|---|---|---|
| 官方維護狀態（2026 年） | 終止維護超過 3 年，無任何修補 | 2025 年 12 月底終止維護 | 8.2 安全維護至 2026 年 12 月；8.3 至 2027 年 12 月 | 主動支援至 2026 年 12 月，安全維護至 2028 年 12 月 |
| WordPress 核心相容性 | WordPress 7.0 仍可運作，但官方最低推薦早已提升 | WordPress 6.x 全系列相容；7.0 前官方標記為「相容」 | 8.2 相容；8.3 於 WordPress 6.8 升為完全相容 | WordPress 6.7 起加入測試支援（Beta 標記），6.9 延續；核心實際運作無重大問題 |
| 外掛生態相容度 | 多數主流外掛維持最低相容，新功能與最佳化不再針對此版開發 | 相容性廣泛，但收到廢棄警告（Deprecated Notice）的外掛明顯增多 | 主流外掛大多更新至完全相容，需留意超過 6 個月未更新的外掛 | 主流外掛（含 Elementor、WooCommerce 等）已完成相容更新；舊版外掛可能出現廢棄警告或功能異常 |
| 效能基準 | 相對最低；官方效能測試數據顯示約比 8.2 慢 20–30% | 較 7.4 明顯提升；引入即時編譯器（Just-In-Time Compiler）雛形 | 8.2 效能穩定；8.3 在字串與陣列處理上有 5–10% 額外改善 | 目前效能表現接近 8.3，部分場景因新型態最佳化略有提升 |
| 適合對象 | 不建議任何新站點或現有站點繼續使用 | 已在安全維護期外，舊站過渡期可短暫停留，但應盡快升版 | 穩定升版目標；8.3 是目前官方推薦的安全選擇 | 新站或願意跟進主流的現有站點；外掛生態已具備足夠成熟度 |
從這張表的橫切面可以看出一件事：版本越新，安全維護期越長，外掛生態也越向其靠攏，不升版的隱性成本會隨時間遞增。PHP 8.4 的「Beta 支援」標記容易讓人誤解，但這個標籤是 WordPress 核心團隊在確認每一項功能細節前的保守措辭，不是警告外界避免使用——目前測試數據顯示核心與主流外掛在 8.4 上的實際執行情況相當穩定。
升版前的相容性檢查流程
直接把 PHP 從 7.4 跳升到 8.4 是效率最低的做法，因為一旦出問題，難以判斷是哪個版本引發了哪個錯誤。較穩健的路徑是逐版測試，每次只跨一個主版號，隔離每次升版產生的問題。
用網站健康工具確認現況
WordPress 後台的「工具 → 網站健康（Site Health）→ 資訊（Info）」頁面，伺服器欄位會直接列出當前 PHP 版本，以及與 WordPress 建議版本的差距。這是最快的現況確認方式，不需要登入主機後台就能取得。
以暫存環境執行升版測試
直接在正式站切換 PHP 版本，風險集中在萬一發生不相容問題時，對訪客的衝擊難以預測且難以快速回復。較好的做法是在主機提供的暫存環境（Staging）複製一份正式站，或在本機開發環境（如 Local by Flywheel）建立測試站，先在那裡切換到目標 PHP 版本，觀察後台介面、前台顯示，以及主要功能是否正常運作。
逐一確認外掛與主題的更新狀態
相容性問題八成來自外掛，而不是 WordPress 核心本身。進入暫存環境後，開啟瀏覽器的開發者工具並切換到 Console 頁籤，同時把 WordPress 的除錯模式（WP_DEBUG）設為開啟，逐一瀏覽主要頁面，記錄出現 Fatal Error 或 Deprecated Warning 的外掛名稱。接著至 WordPress.org 的外掛頁面確認「測試至 WordPress 最新版本」欄位，以及最近一次更新日期——超過一年未更新且持續出現錯誤的外掛，需要評估是否有替代方案。
在 cPanel 或主機後台切換版本的操作路徑
確認測試環境無異常後，就可以在正式站執行切換。不同主機面板的操作入口名稱略有差異，但邏輯一致。
使用 cPanel 的主機，通常有兩種路徑。舊介面提供「Select PHP Version」工具，點進去後直接用下拉選單選擇版本，儲存後立即生效。新介面改用「MultiPHP Manager」，勾選要切換的網域，右側選擇目標版本，點套用即完成。部分主機商在「PHP Extensions」或「PHP Options」分頁另外提供模組啟停與參數微調，像是記憶體上限（memory_limit）或最大上傳大小，升版後若出現功能異常，可以在這裡比對前後設定是否有出入。
不走 cPanel 的雲端或管理式主機（如 Kinsta、WP Engine、Cloudways 等），通常在各站台的「設定」或「環境」頁面直接提供 PHP 版本下拉選單，操作流程更為直觀。部分平台甚至提供一鍵回退功能，讓站長在發現問題後能在幾分鐘內還原。
切換完成後，回到 WordPress 後台重新開啟「網站健康 → 資訊」確認版本已更新，並瀏覽幾個主要頁面做最終確認。若有使用快取外掛或伺服器端快取，切換後記得清空快取，避免舊快取殘留造成誤判。
版本切換本身只需幾分鐘，真正耗時的是切換前的準備工作。把測試環境、外掛審查、備份這三件事做扎實，切換當下反而是整個流程最輕鬆的一步。