facade 静态调用本质是容器代理，其无实际方法，依赖 __callstatic() 通过 createfacade() 从容器获取服务实例；getfacadeclass() 必须返回容器已绑定的服务标识符（如 'db'），而非类名或路径，否则因容器无法解析而报错。
Facade 静态调用本质是容器代理
Facade 不是真正的静态类，它没有实际方法实现，比如 Db::table() 在 think\facade\Db 类里根本不存在。它的调用能成立，完全依赖于 think\Facade 基类中定义的 __callStatic() 魔术方法——该方法内部调用 static::createFacade()，而后者从容器（Container）中取出对应服务实例。
也就是说，Db::table('user') 真正执行的是容器里 db 标识所绑定的那个 think\db\Connection 实例的 table() 方法。没有容器，createFacade() 就无法解析出目标对象，整个链路就断了。
getFacadeClass() 返回值必须匹配容器绑定标识
每个 Facade 子类必须实现 getFacadeClass()，但这个方法返回的不是类名，而是容器中已注册的服务标识符（如 'db'、'cache'、'log'）。常见错误包括：
- 写成完整类名字符串，比如
return \think\Cache::class，但容器里没绑定\think\Cache::class这个 key - 写成命名空间路径，比如
return 'app\common\MyService'，但该字符串未在容器中显式绑定或自动可解析 - 拼写错误，比如把
'cache'写成'cach'，导致Container::get('cach')抛出InvalidArgumentException: Identifier "cach" is not registered
容器不认类名，只认它自己管理的「服务名」——这是 Facade 和容器强耦合的第一道硬约束。
Facade 的生命周期和依赖注入由容器统一控制
直接 new \think\Log() 会绕过所有配置、驱动选择和处理器注册逻辑；而 Log::info('msg') 走的是 Container::make('log')，这意味着：
- 日志驱动（File、Redis、Sentry）由配置决定，不是硬编码
- 构造参数（如日志等级、路径、格式器）由容器按需注入，无需手动传参
- 单例行为由容器保障，多次调用
Log::info()操作的是同一个实例 - 单元测试时可轻松通过
Container::bind('log', $mock)替换真实实现
这些能力全部来自容器，Facade 只是把这种能力“伪装”成静态调用而已。
不走容器的 Facade 会彻底失效
如果你删掉框架启动时的容器初始化，或手动清空容器绑定（比如 Container::clear()），所有 Facade 调用都会立即报错。这不是运行时异常，而是设计层面的依赖：Facade 类本身不持有任何业务逻辑，也不缓存实例，每次静态调用都重新查容器、取实例、转发方法。
真正容易被忽略的是——getFacadeClass() 的返回值不是给开发者看的，它是给容器听的指令。写错一个字母，Facade 就变成哑巴，而且错误信息不会提示“你 Facade 写错了”，只会说“Identifier xxx is not registered”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
