facade 是静态代理，通过静态调用转发至容器中实例；直接 new 会绕过容器的生命周期、单例和依赖注入，导致配置失效、事件丢失、测试困难。
Facade 是什么，为什么不能直接 new 类
Facade 不是语法糖，也不是装饰器，它本质是静态代理——用静态调用（比如 Cache::get()）转发到容器里真正的实例上。你写 new CacheManager 会绕过服务容器的生命周期管理、单例控制、依赖注入，导致配置不生效、事件监听丢失、测试难 mock。
常见错误现象：Class 'App\Facades\CustomFacade' not found 或调用时抛 Call to undefined method App\Facades\CustomFacade::xxx()，基本都是没注册别名或没绑定实现类。
- 必须在
config/app.php的'aliases'数组里加一行映射，比如'MyService' => App\Facades\MyServiceFacade::class - 必须在
AppServiceProvider::register()或专用 provider 里用$this->app->singleton()绑定具体实现类 - Facades 类本身只需继承
Illuminate\Support\Facades\Facade，并实现getFacadeAccessor()返回绑定键名（如'my_service'）
怎么写一个可用的自定义 Facade
以封装一个发短信服务为例：你要的是 Sms::send('138xxx', 'hello') 这种调用，背后走的是 SmsService 实例。关键不在 Facade 类，而在三处联动是否对齐。
示例片段：
// app/Facades/Sms.php
<?php
namespace App\Facades;
use Illuminate\Support\Facades\Facade;
class Sms extends Facade
{
protected static function getFacadeAccessor()
{
return 'sms.service'; // 必须和 bind 的 key 一致
}
}
对应绑定逻辑（在 AppServiceProvider@register 中）：
$this->app->singleton('sms.service', function ($app) {
return new \App\Services\SmsService(
$app->make('http.client'), // 可注入其他服务
config('services.sms.api_key')
);
});
Facade 调用失败的三个高频原因
不是 Facade 写错了，而是上下文断了。绝大多数报错都卡在这三步中的某一个。
-
Class not found：检查composer dump-autoload是否执行；确认app/Facades/目录在autoload["psr-4"]里已声明（默认 Laravel 已配好，但重命名或移动目录后容易漏） -
Call to undefined method：检查getFacadeAccessor()返回的字符串，是否和bind/singleton时用的 key 完全一致（区分大小写、空格、点号） - 方法调用没效果或参数不对：确认你绑定的实现类里，对应方法是 public 的，且签名和 Facade 调用时传入的参数能匹配；不要在 Facade 类里重写方法——它不参与逻辑
Facade 和普通辅助函数 / 依赖注入比有什么代价
它让调用变短，但也带来隐式依赖、测试隔离成本上升、IDE 跳转不直观等问题。不是所有工具类都适合做成 Facade。
- 静态调用无法被 PHPStan/PHPStorm 静态分析准确推导返回类型，
Sms::send()的返回值类型需靠 phpdoc 补充，否则类型提示失效 - 单元测试中，如果没用
swap()或shouldReceive()替换底层实例，就测不到真实行为；而构造注入可以直接 new mock 传进去 - 在非 Laravel 环境（如纯命令行脚本、Worker 进程）里，Facade 依赖应用容器启动完成，早于
app()->booted()就调用会报Application is not bound
真正该用 Facade 的，是那些高频、跨多层、且生命周期由框架统一管理的服务（比如 Auth、DB、Cache）。自己写的工具类，优先考虑注入，Facade 只是可选项，不是必选项。
