prepend-autoloader 不是 composer 的合法配置项，纯属误传；真正控制加载顺序的是 prependpsr4() 方法调用时机及 vendor/autoload.php 中硬编码的注册顺序：psr-4/psr-0 先于 classmap，files 最先执行但不可控。
prepend-autoloader 是什么，它根本不存在
prepend-autoloader 不是 Composer 的配置项，也不是任何合法的 JSON 字段。你在 composer.json 里写 "prepend-autoloader": true 或类似字段，Composer 会直接忽略它——既不报错，也不生效。这个说法常源于对 repositories 配置中 "prepend": true 的误传，但该选项只控制包源（repository）的解析优先级，和自动加载器注册顺序完全无关。
真正影响加载顺序的只有注册时机
Composer 的 autoload 行为由 vendor/autoload.php 中生成的加载器注册顺序决定，而这个顺序是硬编码固定的：
-
psr-4和psr-0加载器最先注册（通过spl_autoload_register） -
classmap加载器其次注册 -
files脚本最后被无条件require_once——但它不是“加载器”，只是前置执行入口
关键点在于：PSR-4 规则本身没有“优先级”概念，而是靠最长前缀匹配；但多个 PSR-4 映射共存时，谁先注册谁先响应。Composer 总是把你项目根目录的 "psr-4"（比如 "App": "src/"）放在 vendor 包之前注册，所以你的类默认就比 monolog/monolog 的 Monolog 先被尝试加载。
想让自己的命名空间“更早命中”，只能手动 prependPsr4()
如果你需要一个额外的、比项目主 PSR-4 还靠前的规则（例如兼容老系统用的 Legacy），不能靠改配置，得在代码里干预 ClassLoader 实例：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
$loader = require __DIR__ . '/vendor/autoload.php';
$loader->prependPsr4('Legacy\', __DIR__ . '/legacy/');
这样注册的规则会被插到所有已有 PSR-4 规则的最前面，实现真正的“提前命中”。注意：
- 必须在
require 'vendor/autoload.php'之后立即操作，否则其他代码可能已触发类加载 -
prependPsr4()和addPsr4()的区别不是“优先级高低”，而是插入位置：前者插头，后者插尾 - 不要在
files里做这事——files执行时$loader还没返回，无法调用方法
files 的顺序看似可控，实则不可信
你写在 "files" 数组里的路径，比如：
"files": ["src/constants.php", "src/helpers.php"]
看起来是按顺序加载，但一旦引入了第三方包（如 symfony/polyfill）也声明了 files，最终合并后的执行顺序由 Composer 解析依赖图时内部决定，你写的顺序可能被覆盖或打乱。更麻烦的是：
- 某个
files脚本抛出ParseError，整个 autoload 初始化就中断，后续所有类都加载失败 - 它不参与类加载流程，只是全局脚本注入点，别指望它能“覆盖” PSR-4 类定义
- 路径必须写全，相对
composer.json，比如"src/helpers.php"，不能写成"helpers.php"或"./src/helpers.php"
真正容易被忽略的，是 files 的执行时机——它在所有 PSR-4 加载器注册前就完成了，但它的内容却不能依赖任何 PSR-4 类。这点一旦搞反，Fatal error: Cannot declare class 就立刻出现。
