视图是虚拟表，数据库仅存储其定义而非数据，优点包括简化操作、多角度查看、增强安全性和提高数据独立性。
视图共享不是“传数据”而是“让数据在多个视图里自动可用”，关键看你是要一次注入、按需加载，还是全局兜底。
view()->share() 在哪里调用才生效
必须在视图被渲染前执行，最稳妥的位置是 AppServiceProvider::boot()。如果写在控制器构造函数里，只对当前控制器的视图生效；写在中间件里则依赖执行顺序，容易漏掉部分请求。
- ✅ 推荐：在
app/Providers/AppServiceProvider.php的boot()方法中调用View::share('site_name', config('app.name')) - ⚠️ 避免：在 BaseController 构造函数中调用
view()->share()—— 它只影响继承该基类的控制器，且可能因中间件未运行而失效 - ? 注意：
View::share()是静态绑定，值在注册时就确定了；如果传的是对象或 Collection，后续修改会影响所有视图（因为是引用）
View::composer() 怎么绑定到特定视图
它不是“共享数据”，而是“按需注入数据”，适合需要动态查库、权限判断或上下文感知的场景。第一个参数支持通配符，但别滥用 *，否则每次渲染都触发，性能直降。
- ✅ 合理用法：
view()->composer('layouts.app', App\Http\ViewComposers\NavigationComposer::class)或view()->composer(['posts.*', 'pages.*'], ...) - ❌ 危险写法：
view()->composer('*', ...)—— 所有视图（包括 404、邮件模板）都会执行回调，可能触发无关查询 - ? Composer 类里必须实现
compose(View $view)方法，$view->with(...)才能把数据塞进去；不能直接赋值$view->key = $value
compact() 和 with() 混用会覆盖变量吗
不会覆盖，但逻辑容易混乱。两者本质不同：compact() 是构造数组传给 view() 第二个参数，with() 是链式调用 View 实例方法，它们可以共存，但优先级和可读性需留意。
- ✅ 安全组合：
return view('dashboard', compact('title', 'count'))->with('user', auth()->user())—— 数组字段 + 链式追加，互不干扰 - ⚠️ 隐患点：
with()多次传同名 key 会以最后一次为准，比如->with('status', 'draft')->with('status', 'published')，最终视图里$status是published - ? 调试技巧：在 Blade 中临时加
{{ dd(get_defined_vars()) }}，能看清哪些变量真正在作用域里
全局共享数据在 Blade 组件里能用吗
能，但仅限于组件模板文件（.blade.php）本身，不包括通过 <x-xxx> 语法引入的组件属性传递链。也就是说：View::share() 注入的 $site_name 可以在 resources/views/components/header.blade.php 里直接用，但不能自动透传进 <x-header title="xxx"> 的 $title 属性里。
- ✅ 正确做法：组件内直接写
{{ $site_name }}（前提是已用View::share()注册） - ❌ 错误期待：以为
View::share()能替代组件 props，导致在<x-card :data="$site_name">中误用 - ? 补充：若组件需复用全局数据，建议在组件定义时用
@props(['siteName' => $site_name ?? null])显式声明默认值，更可控
真正容易被忽略的是生命周期——View::share() 注册后不可撤销，View::composer() 的回调也不支持条件跳过。一旦写错范围或逻辑，轻则多查一次库，重则污染整个渲染流程。动手前先想清楚：这数据是不是真的每个视图都需要？能不能收窄到 layout 或某几个页面？
