Facade不是语法糖，而是基于容器和__callStatic魔术方法的静态代理机制；门面类通过getFacadeClass()返回服务标识符，由容器解析实例并代理调用，实现Db::table()等静态写法背后调用动态实例方法。
ThinkPHP6.x 的 Facade 不是语法糖，而是一套基于容器和魔术方法的静态代理机制。它让开发者能用 Db::table() 这样的写法，背后实际调用的是容器中管理的 think\db\Connection 实例方法。理解它，关键在三点：门面类本身不实现业务逻辑、__callStatic 拦截调用、容器负责实例创建与依赖注入。
Facade 类怎么“凭空”调用不存在的方法？
门面类（如 app\facade\Db）只做一件事：告诉容器“我要找谁”。它继承 think\Facade，并重写 getFacadeClass() 方法，返回一个字符串标识符（比如 'db'），这个值必须和容器中已注册的服务键完全一致。
当你写 Db::table('user') 时：
- PHP 发现 Db 类没有 table() 静态方法，触发 __callStatic('table', ['user'])
- __callStatic 内部调用 createFacade()，从容器取出 db 对应的实例（通常是 think\db\Mysql）
- 最终执行等价于 $dbInstance->table('user')，只是调用形式被“伪装”成静态
自定义门面的两个必要步骤
想为自己的类（比如 app\common\Sms）添加静态调用支持，必须完成以下两步，缺一不可：
立即学习“PHP免费学习笔记（深入）”；
- 创建门面类，放在 app\facade\Sms.php，命名空间为 app\facade，内容如下：
namespace app\facade;
use think\Facade;
class Sms extends Facade
{
protected static function getFacadeClass()
{
return 'sms'; // 注意：不是类名，是容器绑定键
}
} - 在容器中绑定服务，例如在 app/common/ServiceProviders/SmsProvider.php 中注册：
$this->app->bind('sms', \app\common\Sms::class);
或在 app/bootstrap.php 中直接写：
\think\Container::getInstance()->bind('sms', \app\common\Sms::class);
常见报错原因和快速排查方向
遇到 Call to undefined method 或 Identifier "xxx" is not registered，基本可按顺序检查：
- 确认 config/app.php 中 'facade' => true 已启用（TP6 默认开启，但多应用或手动改配后可能关闭）
- 检查门面类路径是否为 app\facade\Xxx.php，类名与文件名严格一致，命名空间正确
- 运行命令生成代理缓存：php think optimize:facade（上线前必须执行，否则清缓存后失效）
- 重点核对 getFacadeClass() 返回值：必须是字符串、小写、无反斜杠、与容器绑定键完全匹配（如返回 'sms'，就不能绑成 'Sms' 或 'app\common\Sms'）
Facade 和直接 new / 依赖注入的区别
Facade 的价值不在写法简洁，而在统一管控实例生命周期和可测试性：
- 用 new \app\common\Sms()：所有依赖（如配置、HTTP 客户端）需手动传参，无法复用、难替换、难 Mock
- 用依赖注入（如 public function send(Sms $sms)）：支持接口类型约束，适合控制器层
- 用 Sms::send()：底层仍走 Container::make()，自动注入依赖，且支持 Container::mock('sms', ...) 在测试中拦截行为
