facade 是 laravel 为解耦服务获取与实现而设计的代理层，不能直接 new 因其绕过容器管理；自定义需三要素齐备：门面类、接口、容器绑定，且 getfacadeaccessor() 必须返回绑定键名而非类名。
Facade 是什么，为什么不能直接 new 一个服务？
Facade 不是语法糖，而是 Laravel 为了解耦「服务获取方式」和「服务实现」设计的代理层。你写 Cache::get('key')，背后调用的其实是 Illuminate\Contracts\Cache\Repository 接口的具体实现（比如 FileStore 或 RedisStore），而这个具体实例由服务容器在运行时注入——你根本不需要知道它在哪、怎么构造。
直接 new FileStore(...) 看似快，但会绕过容器的单例管理、依赖注入、事件监听、装饰器链（比如缓存前/后钩子），也破坏了测试可替换性。Laravel 的核心服务（如 Auth、DB、Mail）都走这套机制，不是为了炫技，是为可维护性留余地。
自定义 Facade 必须配齐三样东西
缺一不可：一个门面类（继承 Facades\Facade）、一个服务接口、一个绑定到容器的实现类。漏掉任何一环，调用时就会报 Target class [xxx] does not exist 或 Call to undefined method。
- 门面类里必须重写
getFacadeAccessor()，返回服务在容器中的绑定键名（比如'mylogger'） - 在
AppServiceProvider::register()里用$this->app->singleton('mylogger', MyLogger::class)绑定实现 - 确保该门面类已加到
config/app.php的'aliases'数组中，例如'MyLog' => App\Facades\MyLog::class
常见错误：把 getFacadeAccessor() 返回值写成类名而非容器键名；或忘了在 register() 中绑定，只写了 bind() 却没调用 resolve()。
Facade 调用失败时，先查容器绑定状态
报 Class xxx does not exist 或 Call to undefined method，大概率不是 Facade 写错了，而是容器里压根没绑好服务。别急着改门面，先验证绑定是否生效：
- 在
tinker里执行app()->bound('mylogger')→ 应返回true - 执行
app('mylogger')→ 应能成功实例化，且类型正确 - 检查绑定是否在
register()而非boot()中完成（boot()太晚，Facade 已初始化）
另外注意：Facade 类本身不参与自动加载逻辑，如果命名空间或文件路径错（比如 App\Facades\MyLog.php 实际放在 app/Support/Facades/），也会触发 Class not found —— 这时候错误信息里的类名才是真实缺失目标。
不要在构造函数里依赖 Facade，它不是服务对象
Facade 是静态代理，本质是运行时动态转发调用。把它当依赖注入进构造函数（比如 public function __construct(MyLog $logger)），PHP 会尝试实例化该 Facade 类，而它没有 __construct()，也不该被实例化，结果就是 Target is not instantiable。
正确做法只有两种：
- 在方法体内直接用静态调用：
MyLog::info('msg') - 若需解耦，应注入接口（如
MyLoggerContract），并在容器中绑定其实现，而不是 Facade 本身
很多人混淆 Facade 和服务契约，以为 Facade 是“可用的服务”，其实它只是个快捷入口。真正可注入、可 mock、可换实现的，永远是接口 + 容器绑定那套。
Facade 看似简单，但它的生命周期完全依赖容器启动顺序、绑定时机和服务解析链。一旦出问题，往往不是 Facade 写得不对，而是绑定漏了、路径错了、或者误把它当普通类用了。
