Blade模板继承通过@extends声明父模板、@section填充区块、@yield预留位置实现；@include安全复用组件；@if自动处理空值；@stack/@push优雅注入JS/CSS。
Blade 模板怎么用 @extends 实现继承
Blade 的模板继承不是靠复制粘贴，而是用 @extends 声明“我基于谁”，再用 @section 填充具体区块。父模板里必须有 @yield 预留位置，子模板才能把内容塞进去。
常见错误是子模板写了 @section 但父模板没对应 @yield，页面直接不显示那块内容，也不报错——这是最容易漏查的静默失败。
- 父模板（比如
resources/views/layouts/app.blade.php）必须包含@yield('content')这类占位 - 子模板开头第一行就得写
@extends('layouts.app')，路径是“点号分隔的视图名”，不是文件路径 -
@section('content')...@endsection和@yield('content')的字符串名必须完全一致，大小写敏感 - 如果子模板想追加而非覆盖父模板某区块，用
@parent：比如@section('title')首页 - @parent@endsection
Laravel 为什么推荐用 @include 而不是直接 PHP include
Blade 的 @include 是编译期处理，能自动传入当前作用域变量，还能安全处理未定义变量；原生 include 是运行时 PHP 行为，变量要手动 extract()，且容易暴露敏感数据或触发未定义变量警告。
典型场景是复用表单字段、分页组件或侧边栏。比如 @include('partials.form-input', ['name' => 'email'])，子视图里直接用 $name，不用再 isset($name) 判断。
-
@include会自动检查视图是否存在，不存在时报明确错误View [partials.form-input] not found - 传参必须是数组，键名变成变量名，值支持表达式：
@include('alerts', ['type' => $alertType ?? 'info']) - 不要在
@include里传大对象或查询结果集——Blade 编译后仍要执行 PHP，可能重复渲染或拖慢响应
Blade 模板里 @if 和 PHP 原生 if 的实际差异
表面看 @if($user->isAdmin()) 和 <?php if ($user->isAdmin()): ?> 效果一样，但 Blade 版本会自动处理空值、布尔转换和异常捕获；原生写法一旦 $user 为 null，就直接报 Call to a member function isAdmin() on null。
更关键的是可读性：Blade 指令统一缩进、无 PHP 标签干扰，嵌套三层以上时维护成本明显更低。
-
@if内部支持 Laravel 的辅助函数，比如@if(auth()->check())，比<?php if (Auth::check()): ?>少打字也少出错 -
@unless是@if(!...)的语法糖，语义更清晰，比如@unless($post->published) - 避免在
@if里写复杂逻辑——该抽成 View Composer 或 Accessor 的，别堆在模板里
为什么 @stack + @push 比全局变量更适合 JS/CSS 注入
当多个子模板都要加自己的 JS，又不能破坏父模板的 <head> 结构时，@stack('scripts') 和 @push('scripts') 是唯一干净解法。用全局变量或多次 @include 容易顺序错乱、重复加载、甚至脚本报错后阻塞后续资源。
典型错误是把 @push 放在 @section 外面——它只在当前渲染上下文中生效，必须在 @section 内或顶层直接写，且父模板的 @stack 必须在对应位置（如 </body> 前）。
- 父模板中
<script src="/js/app.js"></script>@stack('scripts')，子模板用@push('scripts')<script>console.log('page-specific');</script>@endpush - 同一个 stack 名可被多次
@push，按渲染顺序追加，不是覆盖 - 不要用
@stack传大量 HTML 片段——它不校验结构合法性，闭合标签错位会导致整个页面解析失败
事情说清了就结束。模板继承本身不难，难的是在多人协作时保持 @yield 命名一致、@stack 位置统一、以及克制在 Blade 里写业务逻辑的冲动。
