Facade 通过重写的 __callStatic() 魔术方法将静态调用转发给容器中解析出的实例对象：先调用 getFacadeAccessor() 获取服务名，再通过 $app->make() 解析实例，最后调用该实例的同名方法。

Facade 是怎么把静态调用转给实例方法的？

Facade 不是真正的静态类，它只是个“中间人”：你写 Cache::get('key')，实际执行的是容器里某个 Illuminate\Cache\Repository 实例的 get() 方法。关键在 __callStatic() 魔术方法——所有 Laravel Facade 都继承自 Illuminate\Support\Facades\Facade，而这个基类重写了该方法。

它干了三件事：

• 通过 getFacadeAccessor() 拿到服务名（比如 'cache'）
• 从应用容器 $app 中解析出对应实例（$app->make('cache')）
• 把静态调用转发给该实例的同名方法（$instance->get(...)）

为什么 Facade::getFacadeRoot() 返回的是对象而不是字符串？

getFacadeRoot() 是 Facade 类里一个可重写的钩子方法，它的默认实现就是调用容器解析一次并缓存结果。重点在于：它返回的是**已解析的实例对象**，不是类名或服务名。如果你看到它返回 null，大概率是 getFacadeAccessor() 返回的服务名拼错了，或者该服务没被注册进容器。

常见错误现象：

• Call to a member function get() on null —— getFacadeRoot() 返回了 null
• 改了服务提供者但 Facade 没更新 getFacadeAccessor()，导致解析错对象
• 在测试中 Mock 了容器但没正确绑定，Facade 仍试图解析真实实例

自己写一个 Facade 要注意哪几个硬性步骤？

手动实现一个可用的 Facade，必须满足三个条件：

• 类继承 Illuminate\Support\Facades\Facade
• 重写 getFacadeAccessor()，返回容器中已绑定的服务名（如 'my.service'）
• 确保对应服务已通过服务提供者或 AppServiceProvider::boot() 绑定到容器：$this->app->singleton('my.service', MyService::class)

class MyServiceFacade extends Facade
{
    protected static function getFacadeAccessor()
    {
        return 'my.service';
    }
}

别漏掉服务绑定这步——Facade 本身不创建实例，它只负责“找人干活”。没绑定，就找不到人，getFacadeRoot() 就是 null。

Facade 和直接使用 app() 有什么实质区别？

本质没区别，都是从容器取实例。但差异体现在可读性和耦合上：

• app('cache')->get('key') 显式依赖容器 API，测试时容易因硬编码字符串出错
• Cache::get('key') 抽离了服务名，语义清晰；且 Facade 类可被 Mock::swap() 替换，便于单元测试
• 性能上几乎无差别——Facade 第一次调用才解析实例，之后复用缓存结果，和 app() 的 singleton 行为一致

真正容易被忽略的点：Facade 的静态调用看起来像全局函数，但它背后强依赖 Laravel 应用容器的生命周期。如果在容器未启动（比如命令行早