直接删掉 composer.json 中重复的包声明项，再运行 composer update；重复声明会导致依赖解析失败、锁文件异常或 autoload 冲突，需人工搜索确认并同步更新 lock 文件与 vendor 目录。
直接删掉重复的包声明项，再跑 composer update —— 不要只改 composer.json 就扔着不管，否则 composer.lock 和 vendor/ 会不一致，报错是必然的。
怎么发现 composer.json 里有重复包
Composer 本身不校验重复声明，但重复出现在 require 或 require-dev 里会导致 composer update 报错或行为异常（比如版本冲突、锁文件写入失败）。常见现象：
-
composer update卡在解析依赖阶段，终端输出类似Package vendor/name is listed multiple times的警告（某些版本会静默覆盖，但不可靠） -
composer show vendor/name显示两个不同版本，说明锁文件里存了歧义记录 - 手动打开
composer.json，用编辑器搜索包名，发现同一行或不同位置出现两次（尤其容易发生在合并分支、复制粘贴配置后）
composer remove 不能解决重复声明问题
composer remove 只处理“已安装且被声明”的包，它不会扫描并去重 composer.json。如果你执行 composer remove vendor/name，而该包在 composer.json 中重复写了两行，命令只会删掉其中一行（通常是第一个匹配项），第二行残留，下次 composer update 还会出问题。
- 必须人工检查并删掉所有重复条目，确保每个包名在
require和require-dev中最多只出现一次 - 注意大小写：PHP 包名区分大小写，
monolog/monolog和Monolog/Monolog被视为不同包，但实际会冲突 - 别依赖 IDE 自动补全——有些插件会在你输入时偷偷加一行，回头没注意就重复了
删完重复项后必须同步三处状态
只改 composer.json 是最危险的操作。必须让 composer.lock、vendor/ 和 autoloader 同时对齐：
- 运行
composer update vendor/name（精准更新该包）或composer update（全量更新）——推荐前者，更快更可控 - 验证
composer show vendor/name输出是否唯一、版本是否符合预期 - 检查
vendor/composer/autoload_psr4.php是否只有一组该包的映射；若仍有双份，说明composer.lock没刷新干净，可删掉composer.lock再composer update - CI 或 Docker 构建中，务必加
--no-dev（生产环境）或确认require-dev已清空重复项，否则composer install可能拉错包
为什么有时候删了重复项还报 autoload 错误
因为 composer dump-autoload 不会自动清理旧映射，尤其是用了 --classmap-authoritative 或 --optimize 的项目。残留的 classmap 条目仍指向已删路径，导致 Class not found。
- 强制重建：运行
composer dump-autoload -o --classmap-authoritative - 检查
vendor/composer/autoload_classmap.php，确认重复包的类路径已消失 - 某些框架（如 Laravel）会缓存 autoloader，部署后需清应用缓存：
php artisan config:clear、php artisan cache:clear - 如果用了 OPCache，可能需要重启 PHP-FPM 或调用
opcache_reset()，否则旧映射仍在内存里
重复声明不是边缘情况，而是日常协作中最容易被忽略的“隐性污染”——它不立刻崩，但会让后续每次 composer update 变得不可预测。真正麻烦的从来不是删不掉，而是删了一半还留着半截影子。
