blade 模板中不应直接调用 app()->make() 获取服务，因其导致硬编码、无法利用容器单例/自动解析/环境切换，且每次渲染重复解析影响性能；应通过 view::share()、视图 composer 或自定义 blade 指令配合容器绑定来解耦复用。
Blade 模板里不能直接“注入服务”，app() 或 resolve() 是临时取实例的权宜之分，真要复用、解耦、可测试，必须走服务容器绑定 + Blade 指令或视图 Composer。
为什么不能在 Blade 里写 app()->make(MyService::class)
这看似能跑通，但会埋下三个坑：
- 硬编码类名，重构时全局搜不到调用点
- 无法利用容器的单例、依赖自动解析、环境切换（比如测试时 mock）
- Blade 编译后是 PHP 代码，每次渲染都触发一次容器解析，性能微损且掩盖了设计问题
推荐方案：用 View::share() 或视图 Composer 预加载服务
适合需要在多个模板中统一暴露的服务（如当前用户权限、站点配置），避免每个 @include 都重复取实例：
// 在 AppServiceProvider@register() 或 boot() 中
use Illuminate\Support\Facades\View;
use App\Services\NotificationService;
View::share('notifications', app(NotificationService::class));
然后在 Blade 里直接用：{{$notifications->unreadCount()}}。注意：这不是“注入”，而是共享变量；若服务有状态或需按请求隔离，务必确认它是无状态的，或改用视图 Composer。
更干净的做法：注册自定义 Blade 指令 + 容器绑定
把服务逻辑封装成指令，既保持模板简洁，又让服务生命周期由容器管理：
// 在 AppServiceProvider@boot()
use Illuminate\Support\Facades\Blade;
Blade::directive('notifyCount', function () {
return '<?php echo app(\App\Services\NotificationService::class)->unreadCount(); ?>';
});
同时确保服务已绑定（默认单例）：
// 在 AppServiceProvider@register() $this->app->singleton(\App\Services\NotificationService::class);
模板中使用：@notifyCount。好处是模板不感知服务类路径，也不用传参，后续换实现只需改绑定，指令体不动。
别忽略服务构造函数里的依赖陷阱
如果服务本身依赖 Request、Session 或带请求上下文的对象，直接 app(Service::class) 在 Blade 里可能报错——因为容器尝试在非 HTTP 上下文中解析这些对象：
- 错误现象：
Target [Illuminate\Http\Request] is not instantiable - 解决方法：改用
request()辅助函数，或在服务内延迟获取（如用app('request')放在方法里而非构造函数） - 更稳妥：这类服务不该在视图层直接调用，应由控制器预处理好数据再传给视图
真正该进 Blade 的，是纯展示逻辑或无上下文依赖的服务。复杂业务判断，哪怕只差一行，也该留在控制器或 View Composer 里做。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
