laravel全局传参应优先使用appserviceprovider::boot()中view()->share()共享静态数据；动态请求数据用view composer；局部统一需求通过basecontroller封装with()方法实现。
在 Laravel 中，“全局传参”不是定义一个 PHP 变量那么简单，而是通过视图共享机制，让某些数据自动出现在所有（或指定） Blade 模板中。关键不在“怎么写”，而在“在哪写、怎么组织、何时生效”。下面这几种方式覆盖了绝大多数实际场景，按推荐优先级排列。
用 view()->share() 在 AppServiceProvider::boot() 中统一注册
这是最轻量、最稳妥的全局静态数据共享方式，适合网站名称、调试开关、基础配置等不依赖请求上下文的数据。
- 打开
app/Providers/AppServiceProvider.php，在boot()方法里添加：
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
class AppServiceProvider extends ServiceProvider
{
public function boot()
{
view()->share('site_name', config('app.name'));
view()->share('is_local', app()->environment('local'));
view()->share('copyright_year', date('Y'));
}
}
- 这些变量在任意 Blade 文件中可直接使用：
{{ $site_name }}、{{ $is_local ? '开发中' : '' }} - 切勿放在中间件、控制器或模板里调用
view()->share()—— 容易被覆盖或执行多次
用 View Composer 绑定动态请求数据
当要共享的数据和当前用户、路由、权限或数据库查询强相关（比如未读消息数、侧边栏菜单、用户头像），就必须用 View Composer。它会在目标视图渲染前自动执行，支持延迟计算。
- 创建专用服务提供者（如
ViewComposerServiceProvider），在boot()中注册：
View::composer(['layouts.app', 'admin.*'], function ($view) {
$user = auth()->user();
$unread = $user ? $user->notifications()->unread()->count() : 0;
$view->with('unread_count', $unread);
});
- 匹配模式支持通配符（
admin.*）、数组（多个视图名）、或*表示全部 - 避免在回调里做 N+1 查询；需要时提前用
with()预加载关联关系 - 不要把 Composer 逻辑写进控制器或路由闭包——它必须在服务提供者中注册才可靠
按需封装：用 BaseController + with() 做局部统一
如果只有后台模块或某类页面（如会员中心）需要固定几项数据，又不想动全局共享逻辑，可以走“约定优于配置”的路线。
- 新建
BaseController，在构造函数中准备通用数据：
class BaseController extends Controller
{
protected $commonData = [];
public function __construct()
{
$this->commonData = [
'nav_items' => Nav::active()->get(),
'user_role' => auth()->check() ? auth()->user()->role : null,
];
}
protected function view($view, $data = [])
{
return view($view, array_merge($this->commonData, $data));
}
}
- 子控制器继承它，调用
$this->view('admin.dashboard', ['title' => '仪表盘'])即可自动携带公共数据 - 灵活、易测试、不影响其他模块，适合中大型项目分层管理
不推荐但常见误区
有些做法看似简单，实则埋下维护隐患：
-
在 Blade 模板里写
@php view()->share(...) @endphp：污染视图逻辑，无法复用，多次渲染会重复赋值 -
在中间件里调用
view()->share()：中间件执行早于视图工厂初始化完成，部分变量可能无效 -
Blade 中频繁调用
{{ config('app.name') }}或{{ env('APP_NAME') }}：不是错误，但混淆了“配置”与“视图数据”职责，且env()在生产环境通常不可用
