Facade静态调用实际执行的是容器中绑定实例的同名public方法，若方法为protected则直接报错；ThinkPHP官方Facade方法均为public，自定义Facade需确保目标方法可见性为public。
Facade调用实际走的是实例方法，不是静态类方法
Facade（如 Db::table()）表面是静态调用，背后触发的是容器中绑定实例的**同名 public 方法**。它不绕过 PHP 的访问控制机制，也不会把 protected 方法“变”成可静态调用的方法。
也就是说：Db::table() 等价于 $dbInstance->table()，而 $dbInstance 是一个真实对象——如果它的 table() 方法是 protected，那调用直接失败，和你在控制器里写 $this->table() 却没在当前类或父类中定义一样。
常见错误现象：
Fatal error: Uncaught Error: Call to protected method think\db\Connection::table()- IDE 提示 “undefined method”，但运行时报错更早、更直接
为什么 Facade 会去调用 protected 方法？
通常不是 Facade 主动找 protected 方法，而是你误用了非公开接口，或者继承/扩展时没注意方法可见性。ThinkPHP 官方 Facade 绑定的类（如 think\db\Connection）所有对外提供的链式方法（table()、where()、select()）都是 public；但如果你自己写了自定义 Facade，指向了一个内部工具类，而该类把关键方法设为 protected，就会立刻暴露这个问题。
使用场景举例：
- 你写了个
MyUtils类，把formatData()声明为protected，然后在 Facade 的getFacadeClass()中返回'my_utils'，并在容器里绑定了MyUtils实例 - 接着调用
MyUtilsFacade::formatData($data)→ 触发__callStatic→ 转给实例 → 执行$instance->formatData()→ 报错
怎么确认方法是不是 public？
别猜，直接查源码或用反射验证。ThinkPHP 的核心 Facade 对应类基本都遵循 public 接口原则，但自定义服务极易踩坑。
快速检查方式：
- 打开你 Facade 类中
getFacadeClass()返回的字符串对应的服务类（比如返回'user_service'，就去查容器绑定位置，找到实际类） - 定位到你要调用的方法（如
handle()），确认其声明是public function handle()，不是protected或private - 终端执行：
php -r "var_dump((new ReflectionMethod('think\db\Connection', 'table'))->isPublic());"，返回bool(true)才安全
参数差异不在此处起作用——可见性校验发生在方法调用前，跟传什么参数无关。
修复方案：改 visibility，别绕过
不要试图用 call_user_func_array() + ReflectionMethod::setAccessible(true) 强行调用 protected 方法。这破坏封装，且 Facade 的设计初衷就是提供干净、稳定的 public 接口。
正确做法：
- 将目标方法改为
public（最直接） - 如果该方法本就不该对外暴露，那就别通过 Facade 暴露它；换用其他方式（如注入依赖、调用另一个 public 方法间接处理）
- 检查是否误把模型方法当 Facade 使用（例如
UserModel::where()是非法的，UserModel不是 Facade，也不该有静态where）
容易被忽略的一点：有些 IDE 或静态分析工具（如 Intelephense）会把 Facade 当作“纯静态代理”，误判 protected 方法可用；但 PHP 运行时从不买账——只要不是 public，__callStatic 链条走到最后一步就断。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
