view composer 是解决 view()->share() 无条件执行问题的必要工具，仅在匹配视图渲染时运行，须在 appserviceprovider::boot() 中注册，匹配视图名（如 'admin.*'），避免 n+1 查询，类式结构更利于复用与测试。
视图合成器不是“高级替代方案”，而是解决 view()->share() 无条件执行问题的必要工具——它只在匹配的视图真正渲染时才运行，避免给 API 响应、队列任务、PDF 生成等非视图场景徒增开销。
View Composer 必须注册在服务提供者的 boot() 方法里
注册位置错，整个逻辑就失效。不能写在中间件、控制器、路由闭包或 register() 中：
-
register()阶段服务容器还没完全构建，View门面不可用，会报Call to a member function composer() on null - 中间件里调用，可能被后续中间件或控制器覆盖；且执行时机早于视图准备，
$view实例尚未创建 - 控制器里调用，只对当前响应生效，无法复用到邮件模板、后台页面等其他视图
正确姿势是统一收口到 AppServiceProvider::boot() 或独立的 ViewComposerServiceProvider：
<pre class="brush:php;toolbar:false;">use Illuminate\Support\Facades\View;
public function boot()
{
View::composer(['layouts.app', 'admin.*'], function ($view) {
$view->with('unread_count', auth()->check() ? auth()->user()->notifications()->unread()->count() : 0);
});
}
匹配模式只认视图名，不认文件路径或 URL
传给 View::composer()
view('xxx.yyy') 中的 'xxx.yyy'），不是磁盘路径，也不是路由地址：
-
['auth.login', 'auth.register']✅ 匹配resources/views/auth/login.blade.php -
'admin.*'✅ 匹配admin/dashboard、admin/users/index，但不匹配admin（没有点号） -
'/admin/dashboard'❌ 视图名不含斜杠，这样写永远不命中 -
'admin/*'❌ 通配符只支持.分隔的点号语法，不支持 shell 风格的*
回调里查数据库要防 N+1，别把 View Composer 当控制器用
View Composer 回调本质是“每个匹配视图渲染前自动执行一次”，一旦里面包含循环查询或未预加载的关联，性能会断崖式下跌：
- 错误示范：
foreach ($users as $user) { $user->avatar; }—— 每次访问都会触发新查询 - 正确做法：提前在回调外查好数据，或用
with()预加载，例如User::with('avatar')->get() - 更轻量的选择：把耗时逻辑移到缓存层，比如
Cache::remember('nav_menu', 3600, fn() => ...) - 如果数据依赖请求上下文（如当前用户权限），确保
Auth::check()已稳定，别在未认证时调auth()->user()->roles
类式 View Composer 更适合复杂逻辑和复用
闭包写法适合简单共享，但一旦涉及多个变量、条件分支或需要测试，类式结构更可控：
- 类必须实现
compose(View $view)方法，构造函数里不做重活（服务未全就绪） - 类路径需在
boot()中显式注册：View::composer('layouts.app', GlobalComposer::class) - 类内可注入依赖（如 Repository、Config），但避免传
Request或App实例——它们可能引发序列化失败或副作用 - 调试时可在
compose()开头加Log::debug('GlobalComposer running for '.$view->getName());确认是否触发
真正容易被忽略的是：View Composer 不会自动继承父视图的共享变量，也不受 view()->share() 覆盖影响——它是独立的数据注入通道。混用两者时，务必明确哪部分该动态计算、哪部分该静态兜底。
