应检查方法是否存在、是否拼写正确、大小写是否匹配、是否为public static、类是否已正确加载、命名空间是否准确，并优先使用static::而非self::，避免在静态方法中使用$this。
静态调用报
怎么办
这是最典型的 PHP 静态调用错误，说明你用了
去调用一个根本不存在的方法。不是权限问题，也不是
作用域
问题，就是方法压根没定义。
常见诱因包括：拼写错误（
写成
）、大小写不一致（Linux 环境下类名/方法名严格区分大小写）、方法被声明为
或
却用
从外部调用、或者压根忘了写这个方法。
检查类文件是否已
或
，且路径正确（尤其在 Composer 自动加载未生效时）
确认方法定义前有
修饰符，不能只有
用
或
在调用前做兜底判断（调试阶段很有用）
、
、
混用导致行为异常
这三者看起来都是“静态调用”，但绑定时机和语义完全不同：
绑定到**定义时的类**，
是后期静态绑定（Late Static Binding），指向**运行时实际调用的类**，
明确指向父类。
比如在子类中重写了父类的静态方法，用
仍会调用父类里的
；而
才会调用子类版本。误用会导致逻辑静默错位，而不是报错。
立即学习
“
PHP免费学习笔记（深入）
”；
除非明确需要“冻结到当前类”，否则优先用
替代
只应在子类中显式委托给父类实现时使用，不能在顶层类里用
PHP 8.1+ 对
在 trait 中的使用加了严格限制，注意升级后报错
静态方法里访问
或非静态属性报
静态方法没有对象上下文，
不可用，所有对实例属性（
）或实例方法（
）的访问都会直接崩溃。
容易被忽略的是：有些框架或旧代码习惯在静态方法里 new 一个实例再调用，看似绕过了限制，但若该实例又依赖构造函数注入或生命周期管理，就会埋下隐患。
把依赖显式作为参数传入静态方法，而不是在内部 new 实例
如果确实需要状态，考虑改用单例模式或依赖容器获取服务，而非强塞进静态方法
PHP 8.2 开始对静态方法中引用
的检测更严格，部分隐式引用（如闭包里捕获
）也会触发警告
命名空间与自动加载导致的“方法存在却报未定义”
类存在、方法也定义了，但调用时仍报未定义——大概率是命名空间解析失败。比如你在
里定义了
，却在全局命名空间下写
，PHP 会去找
而非
。
Composer 的 PSR-4 自动加载依赖正确的命名空间声明和目录结构，少一个反斜杠或目录名不匹配，类就加载失败，自然方法也“不存在”。
调用前加完整命名空间，如
确认
语句正确，且没有拼写错误（
少了个
就失效）
运行
强制刷新自动加载映射，尤其在新增类后
静态调用的问题往往不在语法本身，而在上下文耦合太深：类没加载、命名空间断链、继承链理解偏差、或把静态当成“万能工具箱”硬塞实例逻辑。真正难排查的，通常是那些不报错但结果不对的情况——比如
错绑导致缓存没刷新、或自动加载失败后退化到 require 失败却静默包含空文件。
Fatal error: Uncaught Error: Call to undefined method::getUserInfogetuserInfoprivateprotected::includerequirepublic staticstaticmethod_exists($class, $method)is_callable([$class, $method])self::static::parent::self::static::parent::self::foo()foostatic::foo()static::self::parent::self::$thisFatal error: Using $this when not in object context$this$this->prop$this->method()$this$thisApp\Services\UserServicepublic static function create()UserService::create()\UserService\App\Services\UserService\App\Services\UserService::create()useuse App\Service\UserService;scomposer dump-autoload -oself::