composer别名并非原生功能，仅通过autoload映射模拟或replace/provide字段影响依赖解析；需检查composer.json及生成的autoload_ps4.php，删除时须同步清理代码引用、配置和缓存。
Composer 别名（alias）到底在哪个文件里生效
Composer 的 alias 只在 composer.json 的 autoload 或 autoload-dev 的 psr-4 / classmap 下通过 as 语法声明时才起作用——但这是个常见误解。实际上，alias 并不是 Composer 原生支持的字段；所谓“别名”，通常是开发者手动在 autoload 中用 "Old\Ns\" : "New\Ns\" 这种映射模拟的，或靠 files 加载兼容层脚本硬绕过去的。
真正由 Composer 官方解析并用于自动加载的别名机制，只存在于 replace 和 provide 字段中，且仅影响包依赖解析，不改变类加载行为。
- 检查项目根目录
composer.json，搜索"as"、"Old\"、"Legacy\"等关键词，定位伪造别名的 autoload 映射 - 运行
composer dump-autoload -o后，查看生成的vendor/composer/autoload_psr4.php，确认那些映射是否真实写入了加载表 - 若存在
"MyApp\V1\" : ["src/v1/"]+"MyApp\V2\" : ["src/v2/"]两套并存，而 V1 已废弃，就属于典型冗余节点
如何安全删除已废弃的 autoload 映射
直接删 composer.json 里的 PSR-4 条目风险很高：Composer 不会自动清理旧的 autoloader 缓存，也不会扫描代码中是否还有残留引用。必须同步做三件事。
- 先全局 grep 搜索旧命名空间：
grep -r "Old\Namespace" --include="*.php" .，确认无任何调用、继承、use 或字符串拼接使用 - 删掉
composer.json中对应条目，例如移除"Old\App\" : "legacy/src/" - 执行
composer dump-autoload -o && composer clear-cache；注意不能跳过-o，否则优化后的 classmap 不会重建，旧路径仍可能被意外加载
如果项目用了 Symfony Flex 或 Laravel，还要检查 config/ 下是否有 services.yaml 或 app.php 里绑定了旧类名——这些不会被 Composer 自动感知。
用 replace + conflict 阻止历史包意外安装
当项目曾依赖过已下线的私有包（如 acme/legacy-utils），而它的代码已被内联进当前代码库，就必须用 replace 显式声明“我已接管”，否则其他依赖可能试图拉取它，引发冲突或版本错乱。
- 在
composer.json的replace字段中加入："acme/legacy-utils": "self.version" - 同时在
conflict中堵死旧版本："acme/legacy-utils": "（假设你内联的是 1.5+ 功能） - 运行
composer update acme/legacy-utils --with-all-dependencies触发依赖图重算，验证是否真的不再下载该包
注意：若旧包含 bin 脚本或插件逻辑，replace 不会自动迁移这些能力，得手动补全到当前项目 bin/ 或 composer.json#scripts 中。
重构后 autoload 性能下降？检查 classmap 冗余项
清理完别名后反而变慢，大概率是 classmap 区域残留了废弃路径。Composer 的 classmap 是全量扫描生成的，哪怕路径不存在或已空，只要还在 composer.json#autoload.classmap 里，就会触发 is_dir() 和遍历，拖慢 dump-autoload 和首次请求。
- 运行
composer dump-autoload -vvv，观察日志里是否出现Scanning dir xxx (not found)或Skipping non-existent path - 逐条核对
autoload.classmap数组，删掉指向legacy/、old-api/、tests/old/这类已移除目录的条目 - 如有动态生成的 classmap（比如通过脚本注入），确保生成逻辑也同步剔除了废弃分支
一个常被忽略的点：autoload-dev.classmap 往往比主 autoload 更混乱，测试用的兼容桥接类容易长期滞留，务必单独清理。
