全局变量应分两类处理：配置型数据存入config/文件，运行时共享数据用视图composer或中间件+view::share()（需加缓存判断）；禁用appserviceprovider::boot()中反复调用view()->share()。
全局变量该往哪放：别碰 config/，也别塞 AppServiceProvider 的 boot()
Laravel 里所谓“全局变量”，其实分两类：一类是配置型（比如 API 密钥、开关标志），另一类是运行时需共享到所有视图的数据（比如当前用户权限菜单、站点标题）。前者进 config/ 文件，后者不该用 view()->share() 全局硬塞，更不该在 AppServiceProvider::boot() 里反复调用——那会导致每次请求都执行，且无法按需控制作用域。
真正稳妥的做法是：配置走 config/，视图共享走中间件或服务提供者的 register() + 视图 Composer。
-
config/app.php或自定义config/site.php存键值对，用config('site.title')读取 - 需要动态计算的（如用户未读消息数），写个视图 Composer，绑定到具体视图目录，而不是全站强塞
- 如果真要全站可用，用中间件 +
View::share()，但必须加缓存判断，避免重复查库
view()->share() 的坑：不是“一次设置，处处生效”
很多人在 AppServiceProvider::boot() 里写 view()->share('user_menu', $menu)，以为设一次就全局可用。实际它只对后续创建的视图实例生效；已有视图（比如已开始渲染的 blade 模板）收不到，而且一旦中间件或控制器里又调了 view()->share() 同名变量，会覆盖前面的值。
- 它不跨请求，也不跨进程，只是当前请求内视图实例的共享池
- 多个地方调用同名
view()->share()时，后调用的会覆盖先调用的，顺序难控 - 在单元测试或 Artisan 命令中，
view()可能未初始化，直接调用会报Call to a member function share() on null
用视图 Composer 替代全局 share：精准、可测、不污染
如果你的变量只用于 layouts/app.blade.php 或 partials/header.blade.php，就该用视图 Composer 绑定到这些路径，而不是全站广播。它在视图被渲染前触发，逻辑清晰，还能依赖注入服务。
示例：在 app/Http/ViewComposers/MenuComposer.php 中：
public function compose(View $view)
{
$menu = cache()->remember('user_menu_'.auth()->id(), 3600, function () {
return MenuService::forUser(auth()->user());
});
$view->with('user_menu', $menu);
}
- 注册时指定模板路径：
View::composer(['layouts.app', 'partials.header'], MenuComposer::class) - 数据只在匹配的视图中可用，不会泄漏到后台命令或 API 响应里
- 天然支持缓存、权限检查、懒加载，比
view()->share()更可控
配置项 vs 运行时变量：别把 config() 当数据库用
有人把用户头像 URL、实时在线人数塞进 config/site.php，再用 config(['site.online_count' => $n]) 动态改——这完全违背配置的设计意图。Laravel 的 config() 是静态快照，修改只在当前请求内存有效，下个请求就丢，且无法触发事件、不兼容多服务器部署。
- 配置文件适合放
APP_NAME、MAIL_FROM_ADDRESS这类启动即确定、极少变动的值 - 运行时需共享的数据，优先走缓存（
cache()->get()）、数据库字段、或通过视图 Composer 按需加载 - 若真要用配置模拟“全局变量”，至少确保它是只读的，且在
config:cache后仍能被正确读取
复杂点在于：变量到底是“配置”还是“状态”，这个边界一旦模糊，后面查 bug 就得翻三遍代码才找得到源头。
