composer依赖解析采用拓扑排序而非require顺序，确保依赖关系满足后再处理包；psr-4前缀重叠才是类加载错乱主因，需通过最长前缀匹配和prependpsr4()干预加载优先级。
Composer依赖解析不是按require顺序，而是拓扑排序
你改了composer.json里require的顺序，但composer update行为没变——这不是 bug，是设计。Composer根本不读这个列表的排列，它会把所有包的require字段拉出来，构建一张有向图：边 A → B 表示“A 依赖 B”。然后执行拓扑排序，确保每个包只在它的全部依赖都已确定版本后才被处理。
这意味着：
- 即使你把
monolog/monolog写在第一行，只要它依赖的psr/log还没完成版本决议，它就不会被选中 - 同一
composer.json+ 同一composer.lock（或无 lock），每次composer install结果完全一致 -
composer update --with-dependencies可能触发整张图重算，看起来“顺序变了”，其实是解空间被重新探索
冲突报错时，拓扑排序已经失败，别再调换require顺序
当你看到类似Conclusion: don't install symfony/console v6.4.0或Root package requires php ^8.1 but laravel/framework requires php ^8.2这类错误，说明 SAT 求解器在拓扑排序过程中撞到了不可满足约束——此时依赖图里已存在环，或版本区间无交集。调换require顺序毫无作用。
真正该做的：
- 运行
composer show --tree，看哪些包间接拉入了冲突版本 - 用
composer why-not vendor/package:version定位谁在阻止某个版本被选 - 检查
conflict字段是否误写了硬性互斥（比如"conflict": {"php": "^8.3"}但你用的是 PHP 8.3.1） - 删掉
composer.lock再composer update --dry-run -v，让求解器从头跑一次，避免被旧 lock 锚定在局部死胡同
PSR-4前缀重叠才是“加载顺序错乱”的真凶
很多人以为“类没加载对”是因为 Composer 安装顺序或 autoload 注册顺序不对，其实 90% 是 PSR-4 前缀撞车。PHP autoloader 不看注册先后，只按最长前缀匹配。如果两个包都声明了"App": "src/"，那第二个映射根本不会生效；如果一个写"App": "src/"、另一个写"AppHelper": "vendor/pkg/src/Helper/"，后者反而优先——因为前缀更长。
排查步骤：
- 运行
composer dump-autoload -v，检查生成的vendor/composer/autoload_psr4.php里是否有重复或截断的前缀（注意末尾必须带反斜杠："App\": "src/"✅，"App\": "src"❌） - 执行
composer show -a vendor/package，确认每个包实际注册的 PSR-4 规则 - 临时删掉
vendor/composer/autoload_psr4.php，只留autoload_classmap.php，如果 Fatal error 消失，就是纯前缀冲突
想让某类优先生效？别动require，用prependPsr4()
安装顺序 ≠ 类加载顺序。你想让myorg/utils里的MyOrgUtilsHelper比项目自身的AppHelper先被new到？靠改composer.json里require顺序没用。Composer 2.2+ 已禁用同一前缀多路径，且prepend: true对 autoload 无效。
唯一可靠方式是运行时干预：
require __DIR__.'/vendor/autoload.php';
$loader = require __DIR__.'/vendor/autoload.php';
$loader->prependPsr4('MyOrg\Utils\', __DIR__.'/vendor/myorg/utils/src/');
这会把新规则插到 PSR-4 查找链最前面，比所有autoload_psr4.php里固化的内容都早匹配。
复杂点在于：这个操作必须在所有其他类加载之前执行，且不能依赖 Composer 自动生成的 autoloader 入口——否则就晚了。最容易被忽略的，是把它放在index.php最顶上，而不是塞进某个 service provider 或 boot 方法里。
