prepend-autoloader 不影响类加载优先级，它仅控制 Composer autoloader 在 spl_autoload_register() 链中的注册顺序，实际加载由 PSR-4 映射路径匹配顺序决定。
不能通过 prepend-autoloader 让 Composer 优先加载 vendor/ 里的类——这个配置项压根不控制“谁先被加载”，它只决定 autoloader 的注册顺序，且仅对 require 进入的文件生效。
为什么 prepend-autoloader 不影响类加载优先级
Composer 的自动加载机制分两层：PSR-4/PSR-0/classmap 的映射规则 + PHP 的 spl_autoload_register() 注册链。设置 "prepend-autoloader": true 只会让 Composer 的 autoloader 在 spl_autoload_register() 链中排在最前面，但它依然遵守“先查映射、再查文件”的规则。如果项目里有同名类（比如 AppHelper 和 vendor/foo/bar/src/Helper），实际加载哪个，取决于谁的 PSR-4 映射路径更早匹配到该类名，跟 autoloader 注册顺序无关。
- 常见错误现象：
Class 'Helper' not found或意外加载了 vendor 里的旧版类，误以为是 autoloader 顺序问题，其实是 PSR-4 映射冲突或autoload-dev干扰 - 真实使用场景：仅当项目需在 Composer autoloader 执行前插入自定义逻辑（如提前定义常量、切换环境）时才需要
prepend-autoloader - 参数差异：
"prepend-autoloader": true会把vendor/autoload.php中的spl_autoload_register()调用放在所有其他注册器之前；默认为false，则按常规顺序追加
想让 vendor 类“优先”被加载？改 PSR-4 映射才是正解
真正影响类加载结果的是 composer.json 里 autoload 和 autoload-dev 的路径声明顺序和范围。Composer 按照配置中出现的顺序依次扫描映射，遇到第一个匹配就返回，不会继续往下找。
- 确保 vendor 包的类不被项目代码覆盖：检查项目自己的
autoload.ps4是否用了过于宽泛的命名空间前缀（如"": "src/"），这会导致FooBar同时匹配项目src/Foo/Bar.php和vendor/foo/bar/src/Foo/Bar.php - 想强制用 vendor 实现：删掉项目中同名命名空间的 autoload 声明，或缩小其路径范围（比如从
"App\": "src/"改成"App\Service\": "src/Service/"） - 验证方式：运行
composer dump-autoload -o后，打开vendor/composer/autoload_psr4.php，看数组键（命名空间）的顺序是否符合预期
vendor/autoload.php 加载时机与陷阱
很多开发者以为只要 require 'vendor/autoload.php' 就万事大吉，但实际行为受加载位置和上下文影响极大。
- 常见错误现象：在
index.php开头require后，某些类仍报Class not found—— 很可能是框架或启动脚本自己又引入了另一份 autoloader（如 Laravel 的bootstrap/autoload.php），造成重复注册或覆盖 - 性能影响：
prepend-autoloader对性能几乎无影响，但错误的 PSR-4 映射会导致每次类加载都多一次文件系统遍历（尤其在未启用 classmap 优化时） - 兼容性注意：PHP 8.1+ 对重复
spl_autoload_register()更敏感，若多个入口同时require vendor/autoload.php且都设了prepend，可能触发警告
真正关键的不是“谁先注册”，而是“谁先匹配”。盯着 autoload_psr4.php 里的数组顺序，比调 prepend-autoloader 有用十倍。很多人改了半天配置，最后发现只是 src/ 下不小心放了个同名 Helper.php 挡住了 vendor 里的版本。
