facade 是依赖 container 的代理层，所有静态调用均通过 container::make() 实例化真实对象；无容器绑定则 facade 失效，且需正确定义 getfacadeclass() 并确保自动加载。
Container 是 Facade 的底层执行引擎
Facade 本身不持有任何业务逻辑，所有静态调用最终都落到 Container::make() 上。比如你写 Cache::get('key')，Facade 并不会自己去读缓存，而是通过 getFacadeClass() 拿到字符串 'cache'，再交给容器去 make('cache') 实例化——这个实例才是真正的 think\Cache 对象。
这意味着：没有容器绑定，Facade 就是空壳。如果你删掉 config/app.php 里 'cache' => \think\Cache::class 这行绑定，Cache::get() 会直接抛出 BindingResolutionException，而不是静默失败。
Facade::bind() 和 Container::bind() 不是同一层操作
Container::bind('cache', Cache::class) 是告诉容器“当我要 make('cache') 时，用这个类”；而 Facade::bind('app\facade\Cache', 'cache') 是告诉 Facade “当你被静态调用时，请去找容器里叫 'cache' 的那个服务”。
常见错误有两类：
- 只在容器绑了类，但没给 Facade 类写
getFacadeClass()返回对应标识（如返回'cache'），结果静态调用报BadMethodCallException - 在
getFacadeClass()里直接返回类名（如return \app\common\MyService::class），但该类构造函数需要参数，而容器无法自动解析，导致make()失败 - 混淆了
Facade::bind()和Container::bind()的调用时机：前者通常在应用启动时批量注册，后者可随时覆盖已有绑定
Facade 调用不是语法糖，它强制走容器生命周期
直接 new \think\Log() 会绕过容器，日志驱动、处理器、配置全失效；而 Log::info() 必然经过 Container::make('log')，确保拿到的是已注入依赖、已加载配置的完整实例。
这也带来两个实际影响：
- 测试更可控：你可以用
Container::mock('log', $fakeLogger)替换真实日志对象，Facade 调用自动生效 - 单例保障：默认情况下
Log::info()多次调用复用同一个实例，避免重复初始化驱动 - 但要注意
Log::write()在 TP8 已被移除，强行调用会触发BadMethodCallException，因为 Facade 只桥接了 PSR-3 标准方法
Facade 类必须继承 think\Facade，且不能省略 getFacadeClass()
哪怕你只是想代理一个简单工具类，也必须显式实现 getFacadeClass()。返回值可以是容器标识符（推荐），也可以是类名字符串，但后者有严格限制：
- 类必须能被反射安全实例化（无必需构造参数，或参数类型能被容器自动解析）
- 如果类依赖
Config或Env等其他容器服务，直接返回类名大概率失败，应优先绑定为容器标识符再引用 - 别在
getFacadeClass()里写逻辑判断或动态拼接类名——它会被高频调用，且结果会被缓存
最易忽略的一点：Facade 类本身不参与自动加载注册，必须确保其命名空间路径与 Loader::addClassAlias() 或 composer autoload 规则匹配，否则 PHP 找不到类，报 Class not found。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
