“Call to a member function xxx on null”是Facade调用返回null所致，根本原因是getFacadeClass()返回的服务标识（如'db'）在容器中未成功绑定或初始化失败，常见于类加载错误、配置异常、提前调用或服务覆盖。
Facade调用报错“Call to a member function xxx on null”
这是典型的 Facade 静态调用返回了 null，而不是预期的容器实例。根本原因不是 Facade 类写错了，而是 getFacadeClass() 返回的服务标识在容器中未绑定或绑定失败。比如 Db::table() 报这个错，说明容器里 'db' 这个键对应的服务没注册成功。
常见触发点：
-
think\db\Connection类加载失败（如扩展缺失、命名空间拼错） - 数据库配置错误导致连接器构造时抛异常，容器 fallback 为 null
- 手动调用
Container::getInstance()->bind('db', null)或类似覆盖操作 - 在
App::init()前就提前使用了 Facade（如在 config 文件里直接写Db::name('user')->buildSql()）
怎么确认 getFacadeClass() 返回值是否有效
先定位出问题的 Facade 类，比如是 Cache、Log 还是自定义的。打开它的源码（如 think\facade\Cache），看 getFacadeClass() 返回什么字符串 —— 注意它不是类名，而是容器服务标识符，例如 return 'cache';。
然后在调试环境里验证该标识是否真能从容器取出实例：
立即学习“PHP免费学习笔记（深入）”；
dd(app('cache'));
如果返回 null，说明绑定失败；如果报错 Class not found，说明服务类路径不对；如果报错 ConnectionException，说明底层初始化失败（如 Redis 扩展没装）。
别信 IDE 补全 —— 它可能只校验命名空间，不校验容器绑定状态。
为什么 app('xxx') 有值但 Xxx::yyy() 还是 null
这往往是因为 Facade 的 createFacade() 方法被重写或拦截了。检查有没有以下情况：
- 项目中存在同名 Facade 类（如自己建了
app\facade\Db.php），且没正确实现getFacadeClass() - 在中间件或事件中调用了
Facade::clearResolvedInstances()，清空了已解析的实例缓存 - 使用了非标准容器（如替换了
Container实现），但没同步更新 Facade 解析逻辑
最简验证法：在控制器开头加一行 var_dump(Facade::isFacade(new \think\facade\Db()));，返回 false 就说明当前 Db 已不是合法 Facade 实例，可能是被覆盖或 require 错文件了。
TP6+ 中修复 Facade 根对象为空的实操步骤
不要直接改框架源码。按顺序排查：
- 确认
config/app.php中'default_return_type'等基础配置没破坏容器启动流程 - 检查
composer.json的autoload是否漏掉了think\facade\*对应的 PSR-4 映射（尤其升级后忘记composer dump-autoload） - 在
public/index.php开头加Container::getInstance()->setDebug(true);，再触发报错，看容器日志里是否有绑定警告 - 临时替换 Facade 调用为直连容器：
app('db')->table('user')->select()，如果这个能跑通，说明 Facade 代理层断了，重点查__callStatic和createFacade
真正难缠的是某些扩展包在 ServiceProvider 中静默覆盖了核心服务绑定，却不抛异常 —— 这时候得翻 vendor 里那个包的 register() 方法，看它往容器塞了啥。
