先講結論：
- PHP 是程式語言，Laravel 是用這個語言蓋系統的「鋼骨結構」（程式框架，類似 .NET 世界的 ASP.NET MVC）。兩者各有自己的版本與官方支援期限。
- PHP 8.x 版本內的更新（例如 8.3 → 8.4），是小數點後的小更新，相容性調整與測試即可，適合放在保固或維護範圍內。
- 小數點前面變了才是真正的升級：PHP 跨到 9，或框架換大版本（例如 Laravel 12 → 13），工作量接近重新改寫與全面測試，應該另案評估、另案報價。
- 合約裡最好直接寫出版本數字，並把「程式語言」和「框架」分開寫，免得一年後雙方各自解讀。
先分清楚：語言、框架、系統
一套網站系統，大致可以拆成這幾層：
| 層級 | 比喻 | 例子 |
|---|---|---|
| 系統功能 | 房子裡的格局與裝潢 | 使用者看到的畫面、申請流程、後台 |
| 程式框架 | 房子的鋼骨結構 | Laravel（類似 ASP.NET MVC） |
| 程式語言 | 蓋房子用的材料與語言 | PHP |
| 網站伺服器、作業系統、主機 | 地基與土地 | Apache、Linux、實體或雲端主機 |
圖：PHP 8.x 內的小更新像換一批材料；框架換大版本（例如 Laravel 12 → 13）像把整組鋼骨吊起來換掉。
很多人聽到「PHP 升級」，會以為就是把 PHP 換新版本。但實際上，大部分的工作量在框架：框架換大版本時，系統每一個畫面、每一段流程都要重新檢查、改寫、測試。
一個實際案例：以為是同一件事
我們最近完成一套公部門系統的升級：PHP 升到 8.3、框架從 Laravel 5.8 升到 12。這次升級的主體是框架跨了好幾個大版本，團隊三、四個人投入，全系統逐畫面對照才收尾。
驗收前討論保固時，對方承辦提出一個很合理的問題：「保固期間，PHP 8.x 版本內的更新，是不是都含在裡面？」
我們的回答是：可以，以 8.x 為界。小數點後面的更新我們處理；小數點前面變了（例如 PHP 9），就等於再來一次升級。
接著承辦說了一句很真實的話：「我原本以為 8.x 內的升級，都是同一個版本。」
這個誤會很常見，也不是誰的錯。問題在於：
- 對使用單位來說，「8.x」看起來是同一版。
- 對開發方來說，8.3 → 8.4 是一次次版本升級，要做相容性檢查。
- 更大的落差在框架：Laravel 12 → 13 不需要換到 PHP 9，如果合約只寫「PHP 8.x 內含在維護」，框架大升級很容易被一起算進「PHP 小更新」。
所以我們補了一句，請對方寫進合約（或明年度維護的需求說明書）：
Laravel 框架主版本升級另案辦理。
對方也同意了。對使用單位來說，這句話反而是保護：明年被管理或採購單位問到「為什麼維護費之外還要升級費」時，有白紙黑字可以說明。
保固、維護、另案，界線怎麼畫
| 更新類型 | 例子 | 建議歸屬 | 原因 |
|---|---|---|---|
| 程式錯誤修正 | 本次開發範圍內的功能異常 | 保固 | 開發方的交付品質 |
| 同版本安全修補 | PHP 8.3.x、Laravel 12.x 的修補版 | 維護 | 套修補＋測試即可 |
| PHP 8.x 內次版本 | 8.3 → 8.4 | 保固或維護（雙方約定） | 小數點後的更新，相容性調整為主 |
| PHP 主版本 | 8.x → 9 | 另案 | 等於換語言版本 |
| 框架主版本 | Laravel 12 → 13 | 另案 | 等於換鋼骨，工作量接近一次升級案 |
| 主機、作業系統、防火牆 | 硬體、OS、WAF | 依主機在誰手上而定 | 責任邊界要事先講清楚 |
官方支援期限，決定你什麼時候「一定得動」
升級不是想做才做，而是官方停止安全修補之後，弱點掃描會開始掃到問題。以本文撰寫時（2026 年 11 月）官方公布的時程：
- PHP 8.3：安全修補到 2027 年 12 月 31 日。
- Laravel 12：安全修補到 2027 年 2 月 24 日。
- Laravel 13 已在 2026 年 3 月發布，支援 PHP 8.3～8.5，安全修補到 2028 年 3 月 17 日。
也就是說，用 Laravel 12 的系統，框架要升級的時間點（2027 年 2 月），比 PHP 8.3 到期（2027 年 12 月）還早。
這也是為什麼「PHP 8.x 內含在維護」和「框架升級另案」必須分開寫：PHP 還在支援期內，框架可能已經先到期了。
我們的做法是：維護期間持續追蹤官方支援期限，在需要升級之前，先依弱點掃描結果評估，提早通知並提供報價，讓客戶有時間編列預算，而不是到期才臨時處理。
合約裡建議寫清楚的三件事
保固、維護、新需求怎麼區分，可以先看 第一次外包網站或系統？驗收前先了解的五件事。版本界線則建議另外寫清楚：
- 保固起算點與範圍：例如「自驗收合格日起一年，以本次開發範圍內之程式錯誤修正為限」。
- 版本界線用數字寫：例如「PHP 8.x 版本內之更新屬保固／維護範圍；PHP 9 以上另案」。
- 框架另外寫一句：例如「Laravel 框架主版本升級（如 12→13）另案辦理」。
這三句寫清楚，比事後解釋十次都有用。
常見問題
PHP 升級和 Laravel 升級有什麼不同？
PHP 是程式語言，Laravel 是建立在 PHP 上的程式框架。PHP 在同一個主版本內升級（如 8.3→8.4）通常以相容性調整為主；Laravel 換大版本（如 12→13）則牽動整個系統結構，需要逐一檢查、改寫與測試，工作量大得多。
PHP 8.x 版本內的更新，算不算保固？
可以由雙方約定。我們的做法是以 8.x 為界：小數點後的更新含在保固或維護內；跨到 PHP 9 才另案。重點是把版本數字寫進合約。
為什麼框架升級不能含在維護費裡？
框架換大版本等於換掉系統的鋼骨結構，工作量接近一次升級專案，不是例行維護能涵蓋的。把它另案處理，使用單位也能提早編列預算，而不是讓維護費無限擴張。
怎麼知道什麼時候需要升級？
看官方的安全修補期限。官方停止修補後，弱點掃描會陸續掃出問題。建議維護廠商在到期前就提出評估與報價。
官方資料（查核 2026-11-05）
系統要升級、或想先盤點版本與支援期限，可以參考我們的 系統開發服務。
