Blade组件需严格遵循路径、命名和调用约定：视图组件须置于resources/views/components/alert.blade.php，类组件需同时存在app/View/Components/Alert.php与对应视图文件；无类时缺失$attributes合并和命名插槽安全处理能力，易出错。
Blade 组件不是“写完就能用”的黑盒，它依赖明确的路径、命名和调用约定；没生成类也能渲染，但缺了 $attributes 和 $slot 的安全处理能力，容易在属性合并或插槽 fallback 时出错。
组件文件放哪？路径和命名必须严格匹配
Laravel 只在两个位置自动识别 <x-alert> 这类标签：
-
resources/views/components/alert.blade.php（纯视图组件，无 PHP 类） -
app/View/Components/Alert.php+resources/views/components/alert.blade.php（类组件，优先级更高）
路径错一个字母、多一层目录、文件名大小写不一致（比如写成 Alert.blade.php），<x-alert> 就直接报 View [components.alert] not found。下划线命名如 user_profile 会自动转为短横线调用：<x-user-profile>，但文件名仍必须是小写+下划线，不能写成 user-profile.blade.php。
有类 vs 无类：属性和插槽行为完全不同
有没有组件类，决定了你能不能可靠地操作传入的数据：
- 有类（如
App\View\Components\Alert）：构造函数可做类型提示、默认值、参数校验；public $type直接变成模板变量；$attributes是ComponentAttributeBag实例，支持$attributes->merge(['class' => 'btn'])->toHtml() - 无类（只有
alert.blade.php）：所有属性进$attributes，但无法提前过滤或重命名；$slot可用，但命名插槽（如<header>...）必须手动用@isset($header)判断，否则未传时会触发Undefined variable: header - 别混用：如果文件
resources/views/components/alert.blade.php存在，但又建了Alert.php类，Laravel 会走类逻辑；删了类却留着视图文件，<x-alert>仍能渲染，只是失去构造逻辑
$attributes 合并 class 时最容易漏掉 merge()
直接写 <div {{ $attributes }}> 看似省事，但会导致 class 被完全覆盖，父级传的 class="text-sm" 会干掉组件内置的 alert alert-info。正确做法是显式合并：
<div {{ $attributes->merge(['class' => 'alert alert-' . $type]) }}>
{{ $slot }}
</div>
注意：$attributes->merge() 返回新实例，不是原地修改；$attributes->class() 是快捷方法，等价于 $attributes->get('class', '')，但不能替代 merge 做兜底。
命名插槽不输出 = 内容静默丢失
命名插槽（比如 <footer>关闭</footer>）不会自动渲染，必须在组件模板里显式写出变量引用：
- 错误写法：
{{ $slot }}—— 只渲染默认插槽，footer内容彻底消失 - 正确写法：
{{ $footer ?? '' }}或更安全的@isset($footer){{ $footer }}@endisset - 大小写敏感：
<Footer>不等于$footer；<header>对应$header，不是$Header - 空字符串不是 null：
empty($footer)比!$footer更准，因为$footer可能是空格或换行符
真正难调试的是：漏写某个命名插槽的输出语句，页面上什么报错都没有，内容就是不显示——得逐行核对模板里的变量名是否和外部标签完全一致。
