BaseController 构造函数中调用 View::share() 不生效，因请求未解析、认证未初始化；应改在控制器方法内或用 View Composer、Trait 安全共享数据。
直接继承 Controller 写基类不是不行，但容易漏掉生命周期关键点、破坏请求上下文、或让 view()->share() 在某些路由下失效——根本原因在于没搞清「数据注入时机」和「作用域边界」。
为什么 BaseController 构造函数里调用 View::share() 有时不生效
构造函数执行时，Laravel 还没完成请求解析（比如中间件未运行、认证未初始化），auth()->user() 可能为 null，request()->route() 也可能不可用。更隐蔽的问题是：视图渲染发生在控制器方法返回之后，而 View::share() 在构造函数中调用，若该控制器被当作服务容器实例化（如在命令行或事件监听器中），会提前触发，导致数据污染其他请求。
- 只在真正响应 HTTP 请求的控制器中才应共享视图数据
- 构造函数不适合依赖请求态对象（
$request、auth()、session()） - 改用
__invoke()或控制器方法内手动调用view()->share()
BaseController 中如何安全注入用户信息和菜单数据
必须等认证完成、路由绑定完毕后再取数据。推荐在控制器方法开始处统一处理，或用中间件隔离逻辑：
class BaseController extends Controller
{
protected function shareCommonViewData()
{
// 确保 auth 已初始化
if (auth()->check()) {
view()->share('current_user', auth()->user());
view()->share('menu_items', $this->loadMenuFor(auth()->user()));
}
view()->share('app_name', config('app.name'));
}
}
- 在子控制器的
index()、show()等方法开头调用$this->shareCommonViewData() - 避免在
__construct()中调用auth()或查询数据库 - 菜单数据建议加缓存（
Cache::remember('menu:'.$user->id, 3600, fn() => ...)），否则每次请求都查库
比 Base Controller 更干净的替代方案：View Composer
当公共数据与特定视图强绑定（比如所有页面都要渲染顶部导航栏），ViewComposer 比基类更合理：它只在目标视图被渲染时触发，不侵入控制器逻辑，且天然支持缓存和条件加载。
- 创建
app/Http/ViewComposers/NavigationComposer.php - 在
boot()中注册：view()->composer(['layouts.app', 'admin.*'], NavigationComposer::class) - Composer 的
compose(View $view)方法里可安全调用auth()->user()，因为此时请求生命周期已推进到视图阶段
Trait 方式复用比继承更灵活
多个控制器可能只需部分公共能力（比如只共享用户数据，不共享菜单），硬继承 BaseController 会造成耦合。用 Trait 能按需组合：
trait SharedViewData
{
public function withCurrentUser()
{
if (auth()->check()) {
view()->share('current_user', auth()->user());
}
}
}
- 在需要的控制器中
use SharedViewData，然后在方法中调用$this->withCurrentUser() - Trait 不影响类继承链，可与
Controller或其他基类共存 - 注意：Trait 方法不能自动执行，必须显式调用；别指望它像构造函数那样“自动生效”
真正容易被忽略的是：view()->share() 是全局状态操作，一旦在中间件或服务提供者里无条件调用，就会影响所有视图——包括 Artisan 命令生成的邮件模板、队列任务里的 PDF 渲染，甚至测试中的模拟视图。务必确认作用域，宁可多写一行判断，也不要图省事塞进 __construct。
