门面不是静态类，而是通过__callStatic()将调用转发给容器中已注册实例的快捷入口；其本质是服务容器的代理，依赖容器绑定、生命周期管理及配置初始化，不可直接new或mock静态方法。
门面不是静态类，而是服务容器的“快捷入口”
门面（Facade）看起来像静态调用，比如 Cache::get() 或 DB::table()，但它背后根本没定义任何静态方法。它靠的是 PHP 的 __callStatic() 魔术方法，把调用转发给服务容器里真正注册的实例。所以你改不了它的静态行为——它压根就不是静态的，只是“装得像”。
- 误以为门面是工具类？删掉
Facades命名空间、直接 new 类试试，大概率报错或行为不一致——因为缺了容器绑定和生命周期管理 - 想测试门面逻辑？别 mock 静态方法（PHP 不支持），而是 mock 容器中它实际解析的那个服务，比如
CacheManager实例 - 自定义门面时，
getFacadeAccessor()返回的字符串必须和容器 bind / singleton 的 key 严格一致，大小写敏感，多一个空格都解析失败
为什么 DB::select() 能用，但 new QueryBuilder() 会出问题
门面的价值，在于它自动拿到“配置好、连接好、事件注册好”的服务实例。比如 DB 门面背后是 Illuminate\Database\DatabaseManager，它根据 config/database.php 动态创建连接、处理读写分离、注入查询日志器——这些全在门面调用前就完成了。
- 手动 new
QueryBuilder：没绑定连接、没设置 grammar、没走 query event pipeline，->where()可能生成错 SQL，->toSql()也可能崩 - 门面调用链是：
DB::table()->where()->get()→ 容器解析出默认连接 → 构造带 connection 的 builder → 执行前触发building事件 - 如果你在命令行或测试中绕过门面直接操作底层类，记得手动调用
setConnection()和useTable()，否则会提示Call to a member function connection() on null
自定义门面时最容易漏掉的两件事
写个 Payment::charge() 门面看似三步：建类、写 getFacadeAccessor()、注册 service provider——但有俩细节 90% 的人第一次会翻车。
- 没在
config/app.php的'aliases'数组里加映射，比如'Payment' => App\Facades\Payment::class，结果报错Class 'Payment' not found - service provider 的
register()方法里只 bind 了实现类，却忘了调用$this->app->alias('payment', PaymentService::class)——门面靠这个 alias 才能从容器里准确 pull 出来，否则getFacadeAccessor()返回'payment'就查无此键 - 别在门面里写业务逻辑！门面只负责转发。把支付签名、验签、回调处理全塞进
Payment门面？以后换 Stripe 改源码，换 PayPal 还得再改——逻辑该在PaymentService里，门面只留一层薄皮
门面 vs 契约：什么时候该用 CacheInterface 而不是 Cache::get()
门面方便，契约（Contracts）保命。你在控制器里写 Cache::get() 没问题；但一旦要写单元测试、要换缓存驱动、要被其他包复用，契约立刻变得不可替代。
- 依赖注入契约：
public function __construct(CacheContract $cache)，测试时可直接传new ArrayStore，完全隔离 Redis 配置 - 用门面则只能 patch
Cache类或重写容器绑定——测试 setup 成本高，且容易污染全局状态 - 门面适合快速原型、脚手架代码、Artisan 命令里的一次性操作；契约适合核心服务、需长期维护的模块、对外提供的 SDK
- 注意：
Cache门面底层实现的就是CacheContract，两者不冲突，只是使用姿势不同——就像同一把刀，门面是手柄朝外递给你，契约是你自己握紧刀柄
Config::get()、Lang::get()），就会让类和容器强耦合，导致迁移、测试、重构成本陡增。真正的难点不在“怎么写门面”，而在“哪一层该暴露门面，哪一层该收口契约”。 
