Facade 是静态调用容器实例的快捷入口，不是语法糖或代理；需三步实现：真实类、继承 Facade 的门面类（含 getFacadeAccessor）、服务提供者中绑定键值对。
Facade 是什么，不是什么
Facade 不是语法糖，也不是魔法代理——它本质是 static 方法调用的「快捷入口」，背后绑定了一个容器里的实例。你写 Cache::get()，实际执行的是容器中 cache 键对应的那个 Illuminate\Cache\Repository 实例的 get() 方法。
容易踩的坑：误以为 Facade 可以直接 new 或继承来扩展；其实它不能被实例化，也不能当普通类用。所有方法必须通过静态调用，且必须在服务提供者里完成绑定。
自定义 Facade 的三步硬操作
要让 MyTool::doSomething() 跑起来，得同时搞定三样东西：真实类、门面类、服务提供者注册。缺一不可，顺序也不能乱。
- 先写真实工具类，比如
app/Services/MyToolService.php，确保它有 public 方法doSomething() - 再建门面类
app/Facades/MyTool.php，继承Illuminate\Support\Facades\Facade，并重写getFacadeAccessor()，返回字符串'mytool' - 最后在服务提供者（如
AppServiceProvider的register()方法）里绑定：$this->app->singleton('mytool', MyToolService::class)
注意：getFacadeAccessor() 返回的字符串，必须和 bind / singleton 时用的键完全一致，大小写敏感，多一个空格都报 Target class [mytool] does not exist。
为什么 Facade::shouldProxy() 报错？
常见错误现象：Call to undefined method App\Facades\MyTool::shouldProxy()，通常是因为你忘了在门面类里声明 protected static $facadeAccessor = 'mytool';，或者用了旧版 Laravel（getFacadeAccessor()。
不同版本差异：
- Laravel 9+ 推荐用
protected static $facadeAccessor静态属性代替getFacadeAccessor()方法 - Laravel 8 及更早必须实现
getFacadeAccessor()方法 - 不匹配会导致 Facade 基类找不到绑定键，进而触发
__callStatic失败
示例（Laravel 10）：
namespace App\Facades;
use Illuminate\Support\Facades\Facade;
class MyTool extends Facade
{
protected static $facadeAccessor = 'mytool';
}
Facade 和依赖注入比，差在哪
Facade 看起来方便，但会隐藏依赖、阻碍测试、绕过类型提示。比如你在控制器里用 MyTool::doSomething()，单元测试时没法轻松 mock —— 它不走容器解析，不参与自动注入。
真实使用场景中，只在「极少变动的全局工具」（如日志、缓存、配置读取）上用 Facade 合理；业务逻辑层建议坚持构造函数注入，哪怕多写两行 use 和参数。
性能影响几乎为零，但可维护性落差明显：一旦某天你要把 MyToolService 换成带参数的工厂构造，Facade 就卡住不动了，而 DI 只需改一行绑定。
最常被忽略的一点：Facade 类本身不会自动加载进容器，getFacadeAccessor 返回的键名是你手动约定的契约，没人校验它是否真被 bind 过——出问题往往在部署后才暴露。
