Facade::createFacade() 是门面实例解析入口，通过 Container::getInstance()->make($class) 从容器获取实例，其中 $class 来自 getFacadeClass() 返回的已注册服务标识（如 'db'），而非完整类名；若未绑定或自动解析失败，则反射创建实例，但要求类可自动加载且构造函数参数可满足。
Facade::createFacade() 是实例解析的入口
门面类本身不存业务逻辑，Db::table() 这类调用能跑起来，全靠 think\Facade 基类里的 createFacade() 方法。它不是凭空造实例，而是从容器里取——准确说是调用 Container::getInstance()->make($class)，其中 $class 来自 getFacadeClass() 的返回值。
常见错误现象：自己写的门面类调用时报 Class not found 或 Target class [xxx] does not exist，大概率是 getFacadeClass() 返回了错误标识，比如写了类名而非容器绑定键，或写错大小写。
-
getFacadeClass()必须返回容器中已注册的服务标识（如'db'、'config'），不是完整类名，也不是命名空间路径 - 若返回
'app\common\Test'，容器会尝试make('app\common\Test')；但若该类未被 bind 或 auto-resolve 失败，就会报错 - TP6+ 默认开启自动解析，但只对 PSR-4 自动加载路径下的类生效；自定义类建议显式
Container::getInstance()->bind('test', Test::class)
容器中没 bind 就靠反射 new 实例，但有前提
当 Container::make('xxx') 执行时，如果 $this->bind['xxx'] 不存在，容器会尝试用反射创建 xxx 对应的类。这看起来很“智能”，但容易踩坑：
- 类必须可被自动加载（PSR-4 规则匹配），否则反射失败直接抛异常
- 构造函数若有参数且无默认值，反射无法自动注入，会报
Missing argument - 若类依赖其他服务（比如
Test构造需传Cache实例），而Cache又没在容器中注册，反射链就断了 - TP5.1 中，
Container::make()第一次调用app会走 bind 映射，第二次调用think\App才真正用反射创建——这个两层跳转逻辑常被忽略
__callStatic 触发时机和参数传递细节
Db::table('user') 能转发到实例方法，核心是 think\Facade::__callStatic() 拦截并重定向。这个魔术方法内部执行的是：
立即学习“PHP免费学习笔记（深入）”；
call_user_func_array([static::createFacade(), 'table'], ['user'])
注意两点：
- 参数原样透传，不做任何类型转换或包装；传数组就收数组，传对象就收对象
- 如果门面类继承的
Facade版本较老（如 TP5.0.x），__callStatic里可能用了call_user_func而非call_user_func_array，导致多参数调用失败 - 静态调用不能访问
$this，所以所有状态都得靠容器里那个单例实例维持——这也是为什么Db::name('user')->where(...)->select()链式调用能串起来
调试时别只看门面类，重点查容器状态
门面调用失败，90% 的问题不在门面本身，而在容器是否按预期准备好实例。最直接的验证方式是手动调用容器：
dump(Container::getInstance()->has('db'));
或者强制获取：
$db = Container::getInstance()->make('db');
如果这里就报错，说明问题出在容器初始化阶段，比如配置未加载、驱动类缺失、或 bind 语句执行顺序不对（必须在门面调用前完成）。
容易被忽略的是：TP 的容器实例是单例，但 instances 数组里存的是具体对象引用。一旦某个服务在第一次 make 时因异常退出，后续再调用 make 仍会复用失败缓存——这时候需要清空 $container->instances 或重启请求上下文。
