facade通过__callstatic魔术方法和getfacadeclass()配合，将静态调用转为容器中对应实例的方法调用：getfacadeclass()返回服务名或类名，容器据此解析并转发调用。
Facade 是怎么把静态调用转成容器实例的
ThinkPHP 的 Facade 不是真静态，而是“假静态”——你写 Cache::get('key')，实际执行的是容器里 cache 绑定的服务实例的方法。关键在 __callStatic 魔术方法和 getFacadeClass() 的配合。
每个门面类必须实现 getFacadeClass()，返回要代理的类名（比如 'cache' 或完整类名 'think\Cache'）。框架据此从容器中解析出实例，再转发调用。
- 如果
getFacadeClass()返回字符串'cache'，容器会尝试解析别名为cache的服务（通常是闭包或已绑定的实例） - 如果返回完整类名如
'think\Cache'，容器会尝试实例化该类（需满足可自动注入依赖） - 没实现
getFacadeClass()或返回空值 → 报错Facade class not found
自定义 Facade 时 bind() 和 singleton() 的区别
门面能否正常工作，取决于它背后绑定到容器的对象是否就绪。常见错误是：写了门面类、也写了 getFacadeClass()，但容器里压根没注册对应服务。
推荐显式绑定，而不是依赖自动解析：
- 用
$app->bind('my_service', MyService::class)→ 每次获取都新建实例 - 用
$app->singleton('my_service', function ($app) { return new MyService($app->make('db')); })→ 单例，且支持依赖注入 - 直接绑定实例：
$app->instance('my_service', new MyService(...))，适合无构造参数或已初始化对象
注意：bind() 和 singleton() 的第一个参数，必须和门面中 getFacadeClass() 返回的字符串完全一致（大小写敏感），否则容器找不到目标。
为什么 Cache::get() 能用，但 MyFacade::doSomething() 报 Call to undefined method
不是所有方法都能被代理——只有目标实例真正拥有的 public 方法才能调用成功。常见踩坑点：
- 目标类方法是
protected或private→ 门面无法穿透访问 - 目标类没实现该方法，或拼写错误（比如
save()写成store()）→ 报Call to undefined method - 门面类继承了错误的基类（比如没继承
think\Facade）→ 缺少__callStatic支持 - 容器绑定的是数组、字符串等非对象值 → 转发调用时抛
Call to a member function on string
调试建议：在门面类里临时加一行 var_dump($this->getFacadeClass(), $app->resolved($this->getFacadeClass()));，确认类名对得上、且已被容器解析过。
Facade 在命令行或单元测试里失效怎么办
门面依赖容器，而 CLI 环境或测试启动流程可能跳过了完整的应用初始化，导致容器未加载或绑定缺失。
- 命令行下运行
php think hello类命令时，确保你的门面绑定逻辑放在app/provider.php或服务提供者register()方法中，而非仅在 HTTP 生命周期里注册 - 单元测试中，若用
MockApplication，需手动触发绑定：$app->bind('my_service', MyService::class) - 避免在门面类的
getFacadeClass()中做运行时判断（如if (App::runningInConsole())），这会让行为不一致且难调试
最稳的方式：门面只做代理，所有绑定逻辑收口到服务提供者，统一管理生命周期。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
