嗨，我是浪花科技的資深工程師 Eric。

最近我接手了一個號稱「傳家寶」等級的舊 Laravel 專案，打開 resources/views 資料夾的那一刻，我彷彿看到了義大利麵工廠發生粉塵爆炸——滿地的 @php 邏輯區塊、無限巢狀的 @if、還有那種複製貼上了五十次的 Modal 視窗程式碼。這種「義大利麵程式碼」（Spaghetti Code）不只在 Controller 發生，View 層往往才是技術債最深重的災區。

到了 2026 年，Laravel 已經進化到第 13 版（或更先進的迭代），Blade 模板引擎早已不再只是單純的 HTML 替換工具。如果你還在用傳統的 @include 或是把 Eloquent Model 直接丟進 View 裡面跑迴圈，那你可能正在扼殺專案的可維護性。

今天這篇文章，我們不談基礎語法，要談的是「架構級」的 Blade 最佳實務。我們將結合原子設計（Atomic Design）概念與最新的 Component 特性，教你如何把 View 層整理得像樂高積木一樣乾淨、好維護。

1. 拋棄 @include，擁抱 Component 體系

雖然 @include 依然存在，但在 2026 年的現代化開發中，它應該被視為「次等公民」。為什麼？因為 @include 無法強制規範傳入的數據型別，也難以封裝獨立的邏輯。相比之下，Blade Components（尤其是 Anonymous Components 和 Class-based Components）提供了更強大的封裝能力。

為什麼 Component 完勝？

• 屬性隔離（Attribute Bag）： 自動處理 HTML 屬性合併，不用手動寫 class 拼接邏輯。
• Slots（插槽）： 讓結構更靈活，不再是死板的參數傳遞。
• 強型別支援： 在 Class-based Component 中，你可以利用 PHP 的型別系統來驗證傳入 View 的資料。

❌ 過時的寫法 (@include)：

<!-- 難以維護，變數來源不明 -->
@include('partials.button', ['type' => 'submit', 'class' => 'btn-primary', 'text' => '送出'])

✅ 2026 推薦寫法 (Component)：

<!-- 語意清晰，屬性自動合併 -->
<x-ui.button type="submit" variant="primary">
    <x-icon.send class="w-4 h-4 mr-2" />
    送出表單
</x-ui.button>

2. 引入原子設計 (Atomic Design) 到 Blade 目錄結構

工程師最頭痛的就是「命名」與「檔案歸檔」。在大型專案中，我強烈建議依照原子設計的方法論來組織你的 resources/views/components 目錄。這能讓新進的工程師（或是三個月後的你自己）不用通靈就能找到檔案。

建議的目錄結構：

• Atoms (原子)： 不可再分割的最小單位。例如：按鈕 (Button)、輸入框 (Input)、標籤 (Label)、圖標 (Icon)。
• Molecules (分子)： 由原子組成的簡單群組。例如：搜尋列 (SearchBar = Input + Button)、表單欄位組 (FormGroup = Label + Input + ErrorMessage)。
• Organisms (組織)： 完整的介面區塊。例如：導覽列 (Navbar)、產品卡片 (ProductCard)、頁尾 (Footer)。
• Templates (模板) / Layouts： 頁面的骨架。

實作範例：封裝一個通用的 Input 分子 (Molecules)

這個 Component 自動處理了 Label、Input 本體以及錯誤訊息顯示，大幅減少 View 裡面的重複代碼。

@props(['label', 'name', 'type' => 'text']) // 定義傳入屬性

<div class="mb-4">
    <label for="{{ $name }}" class="block text-sm font-medium text-gray-700">
        {{ $label }}
    </label>
    
    <div class="mt-1 relative rounded-md shadow-sm">
        <input 
            type="{{ $type }}" 
            name="{{ $name }}" 
            id="{{ $name }}"
            {{ $attributes->merge(['class' => 'focus:ring-indigo-500 focus:border-indigo-500 block w-full sm:text-sm border-gray-300 rounded-md']) }}
            @error($name) aria-invalid="true" @enderror
        >
    </div>

    @error($name)
        <p class="mt-2 text-sm text-red-600" id="{{ $name }}-error">{{ $message }}</p>
    @enderror
</div>

3. 拒絕在 View 裡面寫邏輯：善用 View Model 與 DTO

這是 Eric 最常碎念的一點：View 應該只負責顯示，不應該負責計算。

如果你發現自己在 Blade 裡面寫了複雜的 @if ($user->orders->where('status', 'paid')->sum('total') > 1000)，請立刻停下來。這種邏輯難以測試，且讓 View 變得極其脆弱。

解決方案：View Models 或 Presenters

在 2026 年，我們更傾向使用 View Models（視圖模型）將資料「準備好」再丟給 Blade。這可以是一個簡單的 PHP Class，負責將資料庫的原始資料轉換成人類可讀的格式。

// app/ViewModels/OrderSummaryViewModel.php
class OrderSummaryViewModel
{
    public function __construct(public User $user) {}

    public function isVip(): bool
    {
        return $this->user->orders->where('status', 'paid')->sum('total') > 1000;
    }

    public function formattedTotal(): string
    {
        return number_format($this->user->orders->sum('total'), 2);
    }
}

Blade 內的使用變得極其清爽：

@if($viewModel->isVip())
    <x-ui.badge variant="gold">VIP 會員</x-ui.badge>
@endif

<span>總消費：{{ $viewModel->formattedTotal() }}</span>

4. Blade 效能優化：別忘了 View Caching

雖然 Blade 編譯後是 PHP 檔案，速度很快，但在高流量網站下，如果每個 Request 都要重新渲染大量不變的 HTML 片段（例如複雜的選單、Footer），依然是效能殺手。

在 Laravel 13 中，我們可以更積極地結合 Redis 來快取 View 的片段。雖然 Laravel 內建沒有直接的 @cache 指令（需依賴第三方套件或自製 Directive），但我們可以透過 Component 的 shouldRender 方法來控制。

進階技巧：使用 Fragment Caching

如果你不想引入複雜的套件，可以簡單地利用 Cache Facade 包裹渲染邏輯，或者使用像 Redis 進行快取優化。

5. Slot 的進階用法：具名插槽與作用域插槽

很多工程師只會用預設的 {{ $slot }}。但在製作複雜組件（如 Data Table 或 Modal）時，具名插槽（Named Slots）是保持程式碼整潔的關鍵。

<x-ui.modal>
    <x-slot:title>
        刪除確認
    </x-slot>

    <p>您確定要刪除這筆資料嗎？此動作無法復原。</p>

    <x-slot:footer>
        <x-ui.button variant="secondary" @click="open = false">取消</x-ui.button>
        <x-ui.button variant="danger" wire:click="delete">確認刪除</x-ui.button>
    </x-slot>
</x-ui.modal>

這種寫法讓 Component 內部的 HTML 結構（Header, Body, Footer）由 Component 自身控制，而內容由外部注入，實現了完美的「控制反轉」（IoC）。

結論：View 是產品的臉面，請善待它

在 2026 年，全端開發的界線越來越模糊。無論你是寫 Livewire 還是純 Blade，良好的 View 層架構都是專案長久維護的基石。把 Component 當作你的 DSL（領域特定語言）來設計，你會發現寫 HTML 不再是苦差事，而是一種組裝藝術。

如果你發現現有的專案已經無法負荷業務成長，或者 View 層邏輯已經失控，這時候除了重構，也許你需要更系統性的架構檢視。

延伸閱讀

• 你的 Laravel 後台是『義大利麵』還是『積木城堡』？終極 Admin 架構設計指南，打造可傳承的程式碼藝術品
• Laravel 效能卡關？Redis 就是你的神兵利器！從快取到隊列，資深工程師帶你榨乾系統效能
• 前後端分離還是大一統？Laravel + Vue / React 整合全攻略，資深工程師帶你選對路