门面模式是容器+静态代理机制，非语法糖；调用如cache::get()实为__callstatic拦截后经容器解析执行，需继承think\facade并实现getfacadeclass()返回服务标识，否则报错。
门面模式在 ThinkPHP 中不是语法糖，而是容器 + 静态代理的组合机制；直接写 Cache::get() 能跑，不代表它真的“静态”，背后每次调用都经过容器解析、实例化（或复用）、方法转发——这点不理解，后续排查性能或报错时会卡死。
门面类必须继承 think\Facade 并实现 getFacadeClass()
这是硬性前提，缺一不可。框架靠 getFacadeClass() 返回值决定该往容器里取哪个服务实例。
- 返回字符串（如
'cache'）：表示从容器中按绑定名获取，适用于已通过$app->bind('cache', CacheDriver::class)手动注册的服务 - 返回完整类名（如
'\think\cache\Driver'）：容器会自动 new 该类并单例管理，适合无构造参数的核心类 - 返回空或 null：调用时抛出
BadMethodCallException，错误信息里不会提示原因，只说“方法不存在”——容易误判为方法名写错 - 别在
getFacadeClass()里加逻辑判断或配置读取，它可能被多次调用且无缓存，影响性能
Cache::get() 这类调用实际走的是 __callStatic 魔术方法
你写的每一行门面调用，都不是真静态方法，而是被 think\Facade::__callStatic() 拦截后，转给容器实例再执行对应方法。
- 所以
Cache::get()和app('cache')->get()在行为上等价，但前者多一次反射和容器查找开销（可忽略，但要知道） - 如果真实类里没有
get()方法，哪怕门面类里写了同名方法，也会报BadMethodCallException，因为转发目标是真实类，不是门面类本身 - 门面类里不能定义同名 public 方法（比如自己写个
public static function get()），否则会直接命中，跳过容器转发，导致依赖失效或测试难 mock - 调试时可在门面类的
getFacadeClass()返回前加var_dump($class); exit;，确认容器到底要解析哪个类
自定义门面必须确保服务已绑定到容器，且路径能被自动加载
很多人卡在这一步：门面类文件存在、getFacadeClass() 返回正确，但调用时提示“类找不到”或“无法解析”。根本原因通常是容器没注册，或自动加载失败。
- 服务类必须能被 PSR-4 自动加载；若放在
app/service/下，检查composer.json的 autoload 配置是否包含该目录 - 绑定时机很重要：必须在容器初始化完成前完成，推荐在
app/provider/AppServiceProvider::register()里调用$this->app->bind('my_service', MyService::class) - 别在控制器里临时
app()->bind()，门面调用发生在控制器执行前，此时绑定无效 - 使用
use think\facade\Cache是可选的；不 use 也能直接写think\facade\Cache::get()，但别漏掉命名空间——Cache::get()能用是因为 base.php 里配了别名，不是 PHP 自带功能
最常被忽略的一点：门面调用看似简单，但它把“实例获取”这个动作完全隐藏了。一旦真实类构造函数需要依赖其他服务（比如 MyService 依赖 LoggerInterface），而容器里没绑定那个依赖，报错位置会显示在门面的 __callStatic 内部，堆栈极深，很难一眼定位到是构造函数炸了。这时候得翻容器日志，或者临时在真实类构造函数里打点输出。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
