应采用单层继承+组件化拆分：以layouts.app为唯一父模板，用@component/@include复用区块；避免多层继承、深层@section嵌套及@foreach超过两层；数据预处理、权限判断等逻辑须在Controller完成。
Blade模板继承与@yield/@section怎么避免嵌套过深
Blade本身不支持多层模板继承（比如 A extends B，B extends C），强行套用会导致 @yield 找不到定义、渲染空白或报错 Undefined variable: __env。真正简洁的做法是「单层继承 + 组件化拆分」。
推荐结构：layouts.app 为唯一父模板，所有页面用 @extends('layouts.app')；重复区块（如表单头部、数据表格操作栏）抽成 @component 或 @include 子视图。
- 不要写
@extends('layouts.base')→@extends('layouts.admin')这类链式继承 -
@section内容尽量只放当前页面强相关逻辑，避免塞入大量 HTML 结构 - 若需动态控制某区块是否渲染，用
@isset($slot)或传参判断，而非嵌套@if+@section
组件（Component）替代@include时的命名与参数陷阱
用 php artisan make:component Alert 生成的组件默认使用
常见问题：传布尔值失败（type 是字符串，不是布尔）、slot 内容被忽略（没写 {{ $slot }}）、匿名组件路径错误（未按 resources/views/components/ 存放）。
- 需要类型安全时，在组件类的
$casts属性里声明，如protected $casts = ['dismissable' => 'boolean']; - 避免在组件中直接 echo 或调用
view()，会破坏 Blade 编译缓存 - 传复杂变量（如数组、集合）建议用
:attributes或data-*属性配合 JS 处理，而非全量 PHP 渲染
@foreach 嵌套中 key/index 性能与可读性取舍
在表格或树形结构中常出现 @foreach($items as $item) 套 @foreach($item->children as $child)，此时 $loop->index 和 $loop->parent->index 易混淆，且深层嵌套影响编译速度和调试体验。
- 超过两层嵌套时，优先考虑预处理数据：用
Collection::groupBy()或withCount()提前聚合，减少模板内逻辑 - 需要序号时，用
$loop->iteration（从 1 开始）比$loop->index（从 0 开始）更直观，避免手动 +1 - 避免在
@foreach内调用模型关系方法（如$item->tags->count()），应提前with('tags')预加载
自定义指令（@directive）和 @push/@prepend 的真实适用边界
很多人以为 @push('scripts') 是为了解决 JS 加载顺序，其实它本质是「延迟合并内容到指定栈」，而 @pushonce（Laravel 10+）才真正防重复。高频误用是把业务逻辑塞进指令里，导致模板不可测、难调试。
-
@push只适合静态资源引用、简单初始化脚本；含 PHP 变量或条件逻辑的内容，应改用组件或@include - 自定义指令（如
@admin）务必保持无副作用，不要在指令体内执行 DB 查询或修改全局状态 - 如果多个页面都要加同一段 JS，优先建
resources/views/partials/scripts.blade.php，而不是堆砌@push栈
Blade 的简洁性来自约束，不是功能堆砌。最常被忽略的是：模板不该承担数据组装、权限判断、API 调用这些事——那些该在 Controller 或 Request 类里做完，再以干净变量传进来。
