Composer不会自动替换废弃包，仅警告；须通过composer show、Packagist页面「Replaced by」字段及GitHub文档三步交叉验证替代项，并区分直接/子依赖处理，同时手动修复命名空间、方法签名、autoload映射及dev依赖。
废弃包不能靠改 composer.json 里的名字就跑通——它大概率会立刻抛出 Class not found 或 Too few arguments，除非你已手动处理命名空间、构造函数签名、autoload 映射和上游依赖链。
怎么确认一个包真被废弃，且有官方推荐替代？
别信终端那行黄色警告，它可能来自缓存或镜像延迟。最准的是三步交叉验证：
- 运行
composer show vendor/package-name，重点看输出里有没有abandoned : true或replaced by : new/package——后者才是作者盖章的迁移路径 - 打开 https://www.php.cn/link/84ff7015cca989303244d13f1a8146fd，看右上角「Replaced by」字段，Packagist 页面的数据比本地
composer.lock更权威 - 如果前两步只显示
abandoned : true没写替代项，去 GitHub 仓库翻README.md开头或UPGRADE.md，维护者通常在那里写清了“用 A 替 B，但要注意 C”
为什么只改 composer.json 包名就炸？
废弃包的替代者往往不是“同名换壳”，而是重构级变更。比如：
-
guzzlehttp/guzzle:^6升到^7，GuzzleHttp\Client构造函数参数从array $config变成HandlerStack $handler -
monolog/monolog被php-logging/logger替代后，命名空间从Monolog\变成PhpLogging\ - 新包的
composer.json中autoload段没映射原路径？就得全局搜use Monolog\并逐个替换成新前缀 - 注意
autoload-dev里是否引用了废弃包的测试类（如Monolog\Test\TestCase），这类常被忽略导致phpunit直接失败
如何定位谁在偷偷拉入废弃包？
很多废弃包根本没出现在你的 composer.json 里，而是被某个上游依赖硬拉进来的。比如 aws/aws-sdk-php 旧版依赖 guzzlehttp/ringphp，你删了 ringphp，composer update 就会冲突。
- 执行
composer depends vendor/old-package，它会列出所有直接或间接依赖它的包，比如输出laravel/framework 9.52.0 requires monolog/monolog (^2.0)，说明你不能直接remove，得等 Laravel 升级 - 若返回结果里有第三方 SDK 或闭源组件，且它们没提供新版，你就得权衡：锁版本、打 patch、或自己 fork 修复
- 临时应急可用
"replace": { "vendor/old-package": "*" }，但这只是告诉 Composer “假装它存在”，实际代码仍调用旧类——必须同步 patch 上游或自己兜底
替换后必须验证的三件事
执行完 composer remove 和 composer require 后，光跑 composer dump-autoload -o 不够：
- 用
grep -r 'use.*OldNamespace' . --include='*.php'确认命名空间替换干净，尤其注意 traits、interfaces 和测试文件 - 检查新包的
composer.json是否声明了"replaces": {"old/package": "^2.0"}——只有带这个才可能“无缝”；否则别假设兼容 - 全量跑测试，特别是 HTTP 客户端、日志、缓存这些基础设施层；废弃包常在边界 case 行为古怪，新包可能暴露旧逻辑漏洞
最容易被忽略的点是：废弃状态本身不触发任何强制行为，但一旦你升级 PHP 版本、更新其他依赖、或某天 Packagist 下架该包，问题就会集中爆发——而那时你已忘了当初为什么留着它。
