静态方法冲突本质是类名冲突，php只校验类定义而非静态方法，同名类（如helper）在加载时即报fatal error；需通过autoload_ps4.php、classmap或autoload.files定位重复注册源。
静态方法冲突其实是类名冲突
PHP 不会单独校验静态方法是否重复，它只认类定义。只要两个包都声明了 class Helper，哪怕一个只定义 public static function slug()、另一个只定义 public static function format()，new Helper() 或首次调用 Helper::slug() 时仍会触发 Fatal error: Cannot declare class Helper。
常见误判场景：
- 看到报错里有
Helper::slug()就以为是函数或方法级冲突，实际是类加载阶段就崩了 - 在 IDE 里能跳转到方法定义，但运行时报错——说明 IDE 用了静态分析，而 PHP 运行时只看类是否已存在
- 改用
use AppHelper;后报错消失？那只是因为命名空间隔离了，原冲突类仍存在于全局符号表中
怎么快速定位哪个包注册了同名类
别翻源码，直接查 Composer 生成的映射文件：
- 打开
vendor/composer/autoload_psr4.php，搜索Helper（或你的类名关键词），看是否出现在多个路径下 - 如果搜到两行类似
'Helper\' => array($baseDir . '/src/Helper')和'App\Helper\' => array($baseDir . '/vendor/pkg-a/src')，说明前缀不同但类名相同，冲突风险极高 - 运行
composer dump-autoload -v，观察终端输出里是否对同一命名空间扫描了多次（比如连续出现两行Scanning /vendor/pkg-a/src/ for namespace Helper）
classmap 会劫持 PSR-4 导致“看似没冲突却找不到方法”
如果你的项目或某个依赖在 composer.json 中配置了 classmap，且其中包含 Helper.php 文件，那么即使 PSR-4 映射正确，Helper::slug() 也会走 classmap 加载的版本——而这个版本可能不含你要调用的静态方法。
-
classmap是自动加载流程的第一步，命中即返回，完全跳过 PSR-4 推导 - 检查
vendor/composer/autoload_classmap.php是否存在该类的映射，路径是否指向旧版或阉割版文件 - 执行
composer dump-autoload --no-classmap-authoritative临时禁用 classmap 强制模式，验证是否恢复正常
避免静态方法冲突的实操底线
不要指望 Composer 帮你合并方法，它不处理这个层级。真正可靠的做法只有三条：
- 把工具类封装进带明确前缀的命名空间，例如从
Helper改成VendorAUtilsHelper，并在composer.json中收紧 PSR-4 前缀为"VendorA\Utils\": "src/Utils/" - 若必须共用类名，用代理类：新建
src/Compat/Helper.php，namespace AppCompat;，内部用use VendorAUtilsHelper as AHelper;+use VendorBSupportHelper as BHelper;，再按需转发静态调用 - 彻底弃用顶层静态类，改用 PHP 8.2+ 的
namespace function（如function Appslug(string $s): string { ... }），这类函数受自动加载保护，不会因重复 require 崩溃
最麻烦的不是命名冲突本身，而是某个依赖悄悄在 autoload.files 里注册了含 class Helper 的文件——它不走 PSR-4，不进 classmap，却在 vendor/autoload.php 初始化时就被 require 进来，等你第一次调用时才发现崩了。
