门面是容器的快捷入口而非静态方法，通过静态代理机制将调用转发给容器中真实实例；需正确实现getFacadeClass()返回带引号的完整命名空间字符串，类路径须严格匹配。
门面不是“静态方法”，而是容器的快捷入口
新手常以为 Cache::get() 就是类里写了 static function get()，其实不是。它背后走的是容器（Container）+ 静态代理（Facade）机制：每次调用 Cache::get()，框架都会从容器中取出一个真实的 think\Cache 实例，再把方法转发过去。你写的不是静态逻辑，而是一次“动态实例的静态门牌号”。
这意味着：
- 你改了
think\Cache类，所有Cache::get()调用自动生效，不用改调用点 - 测试时可以轻松 mock 容器返回的 Cache 实例，不影响门面写法
- 如果某天想换 Redis 缓存驱动，只要绑定新实现到容器，
Cache::get()仍照常工作
自己写门面时，getFacadeClass() 必须返回完整命名空间字符串
新手最容易错在 getFacadeClass() 返回值不带引号、漏掉 \ 或写错大小写。比如：
protected static function getFacadeClass()
{
return app\common\Test; // ❌ 错：PHP 会当常量解析
return 'app\common\Test'; // ✅ 对：字符串，且首字母小写不重要，但路径必须准确
}
还要注意：
立即学习“PHP免费学习笔记（深入）”；
- 类文件路径要和命名空间严格匹配（如
app\facade\Test类必须放在app/facade/Test.php） - 别名注册不是必须的，但加了能省
use；没加就得写全\app\facade\Test::hello() - 门面类本身不能有构造函数——它不被实例化，只是个代理壳
什么时候该用门面？看调用是否跨了三层以上
如果你在控制器里连续 new 了 Db、Log、Mail、Config 四个类才完成一个动作，就该考虑封装了。但别一上来就给每个工具类都配门面。
适合门面的典型场景：
- 业务流程强编排：比如「下单」要查库存 → 扣减 → 记账 → 发通知，这四步串起来，用
OrderFacade::place()更清晰 - 第三方 SDK 封装：微信支付 SDK 方法多、参数杂，用
WechatPayFacade::unifiedOrder()隐藏签名和验签细节 - 配置中心统一出口：把
Config::get('db.host')、Env::get('APP_ENV')、Cache::get('feature_flag')收拢成AppConfig::databaseHost()
不适合的：
- 单个方法调用，比如只用一次
Filesystem::put() - 纯数据转换类（如
DateHelper::format()），没依赖、无状态、无容器参与
ThinkPHP 6/8 的门面默认已绑定，别重复 bind
框架启动时已在 base.php 或服务提供者里完成了核心类绑定，比如 think\Cache 已映射到 think\facade\Cache。新手自己写门面时，常误以为要手动调用 Facade::bind() 或改容器绑定——不需要。
你只需做三件事：
- 在
app/facade/下建类，继承think\Facade - 重写
getFacadeClass()返回目标类完整字符串 - 在控制器或服务里
use app\facade\YourFacade然后直接YourFacade::method()
真正容易被忽略的是：门面不解决耦合根源，只掩盖调用表象。如果子系统之间本就该解耦（比如库存和支付不该互相调用），光加个门面反而让问题更隐蔽——先理清职责边界，再决定要不要立这块“操作面板”。
