视图 composer 是 laravel 处理全局数据共享最稳妥的方式，因其仅在匹配视图渲染时执行，避免中间件时机错位、session未初始化及无意义开销，且支持精准作用域控制、易测试复用。
视图 Composer 是 Laravel 5.5 中处理全局数据共享最稳妥的方式，比中间件更可控、更易测试，也避免了 View::share() 在请求生命周期中时机错位导致的变量未定义问题。
为什么不用中间件做全局数据注入
中间件里调用 View::share() 看似简单，但容易踩两个坑：一是如果中间件注册在 web 组之外（比如放在 api 中间件组），它根本不会执行；二是即使注册正确，若中间件顺序靠后（比如在 StartSession 之后），会话数据可能还没初始化，session()->get('cart') 返回 null 或抛出异常。
-
View::share()必须在视图渲染前完成，而中间件的执行顺序依赖app/Http/Kernel.php中的$middlewareGroups定义 - 中间件无法区分「哪些视图需要该数据」，强制全局共享会导致无意义的 session 读取和计算开销
- 调试时很难定位是哪个中间件污染了视图变量，尤其当多个中间件都调用
View::share()
如何注册一个针对所有视图的视图 Composer
视图 Composer 的本质是「当指定视图被渲染时，自动执行一段逻辑」。要覆盖所有视图，只需把模板通配符设为 *，但要注意它只匹配实际被 view() 渲染的视图，不包括子视图或 @include。
- 在
AppServiceProvider::boot()中注册：View::composer('*', function ($view) { $cartCount = session()->get('cart', [])->count(); $view->with('cart_count', $cartCount); }); - 更推荐单独建类（如
App\Http\ViewComposers\GlobalComposer），便于复用和单元测试 - 不要在 Composer 中做重操作——比如查数据库或调 API，它会在每次视图渲染时触发
如何让视图 Composer 只作用于特定布局或子集
硬编码 * 太粗暴。Laravel 允许你按命名空间或路径模式精准控制作用域，这对多模板项目（如 admin + frontend）特别关键。
- 限制到某个布局：
View::composer('layouts.app', ...) - 匹配一组视图：
View::composer(['home.index', 'product.*'], ...) - 排除某些视图（需手动判断）：
if (! in_array($view->name(), ['auth.login', 'errors.404'])) { $view->with('cart_count', ...); } - 注意：通配符
product.*匹配product.index和product.show，但不匹配product/category/list（除非写成product.*.*）
视图 Composer 的性能与生命周期陷阱
它不是“一次初始化，全局可用”，而是每次渲染都执行一次闭包或方法。如果你在其中做了重复计算（比如反复解析 JSON、多次调用 session()->all()），性能会明显下降。
- 避免在
compose()方法里调用Auth::user()多次——Laravel 的认证门面本身有缓存，但频繁访问仍增加框架开销 - 会话数据建议用
session()->get('key', $default)而非session()->has('key') && session()->get('key')，减少一次键检查 - 如果数据来自数据库且变化不频繁，加一层简单的缓存：
Cache::remember('global_cart_count', 60, fn() => ...) - 切记：视图 Composer 不会自动继承父视图的数据，
@yield和@include是独立上下文，需各自处理
真正麻烦的不是怎么写这个 Composer，而是想清楚「哪些数据真的需要每页都带」——购物车数量可以，但用户完整资料不行。别为了省几行代码，把所有东西都塞进视图共享里。
