30 天前，Day 1 給了你一張 Laravel 10 到 13 的版本地圖；今天回頭看，我們一起把 blog-app 這個部落格系統從一台空白電腦，蓋成一個有完整 Eloquent 資料模型、RESTful API、佇列、排程、測試、還串了 LINE 聊天機器人並且真正上線的服務。最後一天回顧整趟旅程，再看看幾個很值得你花時間認識、但 30 天裡沒有自然位置安插的 Laravel 13 新能力。
基礎建置（Day 2-8）：從 PHP 8.3+ 環境開始，認識 Laragon/Docker/Sail 三種開發環境選擇，用全新的 Starter Kit 建立認證系統（Breeze/Jetstream 換代成 Fortify 驅動的新方案，含密碼規則客製化、雙因子驗證流程、登入節流保護），接著是這系列改動最大的部分——bootstrap/app.php 取代 Kernel.php 的骨架重構（含 withRouting() 完整參數、Event Discovery 機制），最後把 Config（APP_KEY 的重要性、環境專屬 .env 檔案）、路由（路由模型綁定自訂欄位、簽章網址）、Helpers（Str::of() 鏈式 API、rescue()/retry()）這些基本功打穩。
Eloquent 與 MVC（Day 9-14）：Post/User 資料模型建起來（含多對多 Tag 關聯實作、Factory 自訂狀態）、查詢建構器精選速查表（when() 條件式查詢、whereHas()、chunk()/lazy() 大量資料處理）、casts() 方法與 UUIDv7 這兩個 Eloquent 新功能（含 Enum 轉型的型別安全價值）、View/Blade（Layout 兩種組織方式、Class-Based 元件）、Controller（三種現行的中介層寫法，取代已失效的 $this->middleware()）、最後端到端示範了一套完整的 RESTful API 設計（含條件式欄位輸出、API 版本控制策略、Laravel 13 的 JSON:API 支援）。
架構與內部機制（Day 15-25）：這是份量最扎實的一段——Logging（結構化日誌、Sentry 整合、Pail 即時查看）、Middleware（洋蔥模型的實際執行順序、Terminable Middleware、CSRF 中介層改名這個系列裡少數「Likelihood Of Impact: High」的變動）、Validation（條件式驗證、巢狀陣列驗證、Form Request 的兩個進階 Hook）、Exception（withExceptions() 新寫法、自訂例外階層架構設計）、Queue（Job Chaining/Batch、Queue::route() 與 Job Attribute）、多語系（日期數字在地化、複數規則）、重新畫過的請求生命週期圖（含 Console 生命週期的差異）、PSR/OOP/SOLID 軟體工程基礎（組合優於繼承的具體重構案例）、Service Container/Provider 依賴注入實戰（Facade 背後的容器解析機制）、Session/Cookie（Session Fixation 防護）、Schedule（Schedule facade 取代 Kernel.php、排程任務的執行結果 Hook）。
實戰與生態圈（Day 26-29）：HTTP Client（併發請求 Pool、可重用巨集封裝）、Testing（Unit/Feature Test 差異、CI 整合）、套件生態盤點（Telescope/Sanctum/Octane/Socialite/Laravel Boost，含 Token 權限範圍設計），最後在 Day 29 把所有知識收攏成一次完整的「開發 → 版控 → 上線」實戰演練，特別強調了 Webhook 該透過 Queue 背景處理、而不是同步呼叫外部 AI 服務這個容易被忽略的實務考量。
回頭看這 30 天，版本更新大致可以分成三個層次。之後接手舊專案、或看到舊教學文章時，這個分類架構可以幫你快速判斷該怎麼處理：
casts() 方法（$casts 陣列還能用）、Job 的 PHP Attribute 寫法（public 屬性還能用）。這類變動最好處理，通常兩種寫法可以並存，不需要強制遷移舊專案。Kernel.php 搬到 bootstrap/app.php/routes/console.php。這類是這系列講最多的部分，因為網路上的舊文章大量依賴這些檔案位置來教學。DECISIONS.md 裡記錄最多判斷取捨的地方。
在進入新功能巡禮之前，這裡提供一份簡短的自我檢查清單，如果以下問題你都能大致回答出來，代表這系列的核心內容已經內化成你自己的知識，而不只是讀過一遍：
Kernel.php 消失後，Middleware/Exception/Schedule 這三類設定分別搬去哪裡了？（Day 16、18、25）blog-app 裡新增一個「文章按讚」功能，你會怎麼規劃 Migration、Model 關聯、路由、Controller、驗證、測試？（整合 Day 7-17、27）最後一題特別值得自己動手試試看——如果能不看文章、獨立設計出一套合理的實作方案，代表你已經建立起這系列真正想傳達的「可遷移的心智模型」，而不只是記得幾個指令。
以下幾個功能前面 29 天沒有自然的位置可以安插，但值得你知道它們存在。
blog-app 如果之後想做「文章有新留言時即時通知作者」這種即時互動功能，Laravel 11 推出的 Reverb 是官方第一方的 WebSocket 伺服器方案，跟 Laravel Echo（前端接收即時事件的客戶端函式庫）搭配使用：
php artisan install:broadcasting
php artisan reverb:start
安裝完成後，定義一個可廣播的事件並在前端訂閱：
// app/Events/PostCommented.php
class PostCommented implements ShouldBroadcast
{
public function __construct(public Post $post, public string $commenterName) {}
public function broadcastOn(): Channel
{
return new PrivateChannel("posts.{$this->post->id}");
}
}
// 前端 JavaScript（Echo）
Echo.private(`posts.${postId}`).listen('PostCommented', (e) => {
alert(`${e.commenterName} 留言了！`);
});
ShouldBroadcast 介面讓一個一般的 Laravel 事件（Day 5 提過的 Event Discovery 機制底層的那套事件系統）同時具備即時推送給瀏覽器的能力，PrivateChannel 確保只有經過授權的使用者（例如只有文章作者本人）能收到這則通知，不會被任意訪客監聽到。即時通訊這塊我在第一季也沒真的寫進去，一部分原因是當時的方案（Pusher、laravel-websockets）沒有一個穩定的官方解；現在 Reverb 補上了這個位置，值得單獨花時間認識。
Day 28 介紹的 Laravel Boost，是讓「開發者的 AI 助手」更懂你的專案；Laravel 13 同時推出的 AI SDK 則是完全不同的定位——讓你的應用程式本身串接 AI 能力，提供跨供應商的統一 API：
use App\Ai\Agents\SupportAgent;
use Laravel\Ai\Image;
use Illuminate\Support\Str;
$response = SupportAgent::make()->prompt('幫我用 100 字摘要這篇文章的重點');
$image = Image::of('一隻貓咪坐在書堆旁邊看書')->generate();
$embeddings = Str::of($post->body)->toEmbeddings();
blog-app 如果想做「自動幫文章產生摘要」「自動生成文章封面圖」「用語意搜尋取代單純的關鍵字比對」這類功能，AI SDK 是官方的一站式解法，不需要自己包一層第三方 SDK。跟 Day 29 手動串接 OpenAI 的方式相比，AI SDK 的價值在於供應商中立——同一段程式碼理論上可以切換不同的底層模型供應商，不需要為每一家 AI 服務各自學一套 SDK 用法，這對長期維護、或想要有議價空間不被單一供應商綁定的專案很有意義。
跟 AI SDK 搭配的是原生向量查詢支援，用 PostgreSQL + pgvector 就能做語意相似度搜尋，不需要額外導入專門的向量資料庫：
$similarPosts = DB::table('posts')
->whereVectorSimilarTo('embedding', '如何學習 Laravel')
->limit(5)
->get();
如果 blog-app 之後想做「猜你喜歡」這類推薦功能，這是比傳統關鍵字比對更貼近使用者實際搜尋意圖的做法——傳統的 LIKE '%關鍵字%' 只能比對到字面完全相符的內容，語意搜尋能理解「怎麼學 Laravel」跟「Laravel 入門教學」這兩句話語意相近，即使沒有任何共同字詞，也能正確配對到相關文章。
這系列建立的是「Laravel 13 現在該怎麼寫」的完整地基，如果你想繼續往下鑽研，幾個自然的延伸方向：
laravel.com/docs/{version}/releases 的習慣，這比等下一次大版本跳躍再一次性惡補要輕鬆得多，也是這系列反覆強調的心法。Q：這系列是 Laravel 13 專用的嗎？我用 Laravel 12 可以看嗎？
可以。這系列絕大多數內容從 Laravel 11 骨架重構之後就已經適用（Laravel 11、12、13 共用同一套新骨架心智模型），只有少數明確標記 [NEW] 的 Laravel 13 專屬功能（CSRF 改名、Queue::route()、JSON:API、Boost ^2.0 等）在 12 版還沒有，讀到那些段落時心裡有數即可。
Q：看過第一季的人，要重新從頭學一次嗎？
不需要。核心概念（路由、Eloquent、Middleware 是什麼、Queue 解決什麼問題）一脈相承，真正需要重建的只有「新專案的骨架長什麼樣子」這件事——花一天（Day 5）建立新的心智模型，後面的知識大部分可以直接沿用。
Q：以後 Laravel 14、15 出來，是不是又要整套重學？
不會，而且這正是這系列想傳達的心法：Laravel 團隊一貫盡量減少破壞性變動（Laravel 12、13 官方都明確寫「大部分應用程式可以不改任何程式碼直接升級」），真正影響大的骨架重構（像這次 Laravel 11 做的）不是每年都會發生。保持每年看一次官方 release notes 的習慣，比等三年後再一次補齊落差要輕鬆得多——這也是為什麼這次更新我選擇搭配 AI 協作，把「逐條核對版本差異」這種原本很花時間的工作效率化，讓知識更新這件事可以做得更頻繁、更即時。
Q：blog-app 這個範例專案的完整原始碼在哪裡可以看到？
這系列的每一天都是圍繞著 blog-app 累加式展開的，把 30 天的程式碼片段依照出現順序組裝起來，就是這個專案的完整實作。之所以不額外提供一個獨立的完整 repository，是希望你親手把每一天的程式碼打過一遍——這系列從 Day 1 就強調的「重建直覺」，靠的是實際動手練習，而不是複製貼上一份現成的原始碼。
Q：如果我發現某個章節的技術細節跟我實際測試的結果不一樣，該怎麼辦？
Laravel 官方文件本身偶爾也會有描述不夠精確、甚至前後不一致的地方（Day 25 就實際遇到 withSchedule()/withScheduling() 這個文件本身兩處說法不同的例子）。如果你發現落差，最可靠的做法永遠是回到官方文件或直接讀框架原始碼確認，而不是預設任何一份教材（包括這系列）絕對正確。
當初寫書的時候，其實學到了很多——小從一些 Helper、Facade 的用法，大到依賴注入、SOLID 這些設計原則，都是那段時間紮紮實實補起來的，對我後來的職涯幫助很大。撰寫過程說實話很燒腦，而且最後還出版失敗；但也正是因為出版失敗，才有機會把這份內容拿出來重寫成《我推的Laravel S2》——如果當初順利出版，版權早就不在我手上了，也不會有現在這個系列。
連有 ADHD 的我都能把一本書寫完，你又有什麼理由不開始一場鐵人賽，當作磨練自己的過程呢？
可能有些人會覺得，這系列全程用 AI 協作，算不算是一種作弊？我想說：是，也不是。
說「是」，是因為 AI 確實幫我省下大量時間，也讓文章的正確性提升不少（雖然 AI 還是有可能出錯，這系列裡也不是沒發生過）。
說「不是」，是因為這個系列的底子，是從我之前寫的書抓出來的，AI 做的是幫我把這些內容更新、擴充、重新組織，而不是憑空生成一套我完全沒碰過的東西——過程中審稿、抓截圖、決定哪些該留哪些該砍，這些還是我自己在做，某種程度上也是我在跟 AI 一起學習，而不是單純把工作丟給它。
總之，這個系列到這裡也告一段落了，感謝大家一路收看。
另外，也期待《我推的孩子》第四期。
第一季寫了兩年才完成，S2 則是在 AI 協作下用遠遠更短的時間做完一次同等深度的版本校準與內容重整——這本身就是想傳達的訊息之一：現在的開發者不缺工具幫你把「知道哪裡變了」做得又快又準，真正的門檻已經不是「有沒有時間逐字核對文件」，而是「有沒有能力做出正確的架構取捨、判斷這個新功能該不該用、什麼時候該用」。這 30 天希望帶給你的，除了 Laravel 13 的具體語法，更是這套持續更新自己知識的方法。
感謝你跟著走完 30 天。如果你發現任何不對的地方，或想討論某個章節的取捨判斷，DECISIONS.md 裡記錄了每一個「沒有唯一正確答案」的決定，歡迎回頭對照。
學不可以已 — 《荀子・勸學》
（系列完）
iThome鐵人賽
看影片追技術