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