view()->share() 最安全的调用位置是 AppServiceProvider::boot()，因它在每次请求启动时执行一次且早于视图渲染；不可在 register()、中间件或控制器中调用，否则易引发漏共享、重复、错乱或空引用错误。
view()->share() 在哪里调用最安全
全局共享变量必须在服务提供者里注册，不能写在中间件或控制器里——否则请求一多就可能漏掉、重复或错乱。AppServiceProvider::boot() 是唯一稳妥的位置，它在每次请求启动时执行一次，且早于视图渲染。
- 别在
AppServiceProvider::register()里调用view()->share()，这时视图引擎还没初始化，会报Call to a member function share() on null - 如果只对部分路由生效，用
view()->composer()更精准，view()->share()是真·全局，连邮件模板、PDF 渲染都会带上 - 共享大量数据（比如整个用户权限树）会影响所有视图性能，尤其是缓存失效后首次渲染；建议只放轻量、高频使用的值，如
app_name、current_user（已简化为 ID 或必要字段）
view()->share() 传对象要注意什么
传 Auth::user() 这类 Eloquent 模型没问题，但传 request() 或 app() 实例会导致视图里意外触发副作用，比如重复执行中间件逻辑、提前解析未绑定的服务。
- 避免传
Request对象：它内部持有原始输入和文件句柄，序列化/共享后可能引发Serialization of 'Closure' is not allowed - 传数组比传对象更稳妥：
view()->share('site_config', config('site'))比view()->share('config', config())安全，后者返回的是Application实例 - 如果必须传模型，确保它没加载 N+1 关联（比如
User::with('posts')），否则每个页面都查一遍 posts 表
blade 模板里怎么判断共享变量是否存在
共享变量不是 PHP 变量，是视图实例的上下文数据，直接 isset($foo) 不可靠——它可能被 unset、覆盖，或者根本没被 share 进来。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 用
@isset($foo)或{{ $foo ?? 'default' }}，这是 Blade 层面的安全兜底 - 不要依赖
view()->share()的执行顺序来假设变量一定存在；Laravel 允许在不同地方多次 share 同名变量，后调用的会覆盖前调用的 - 调试时用
{{ dump(get_defined_vars()) }}看当前作用域所有变量，但别留在线上环境
想按域名或路由分组共享不同数据怎么办
view()->share() 本身不支持条件分支，硬塞 if-else 到 boot() 里会让逻辑散乱难维护。
- 用视图 Composer 替代：
view()->composer(['layouts.app', 'emails.*'], SiteDataComposer::class)，在compose()方法里根据request()->getHost()或Route::current()->getName()动态 assign - 多个域名共用一套代码时，把配置抽到
config/site.php，用APP_URL或REQUEST_URI匹配对应站点再 share，比硬编码 if 更易测试 - 注意：Composer 的
compose()在视图渲染前执行，但它不保证只执行一次——如果一个页面 include 多个匹配的子视图，可能反复调用
共享变量看似简单，真正麻烦的是它隐式影响所有视图生命周期。改一个 view()->share()，可能让 PDF 导出失败、邮件内容错乱、甚至 API 响应里混进 HTML 片段。上线前务必检查非 Web 场景是否也被波及。
