abandoned包不能仅靠改composer.json名字解决，必须三步验证：composer show查replaced by、Packagist页面确认、GitHub文档看迁移说明；替换后需手动处理命名空间、方法签名、autoload及配置硬编码，并用composer depends溯源、composer why清残留、全量测试验证。
直接结论：别信“替换”这个词——abandoned包不是换个composer.json里的名字就能跑通的，它大概率要你改代码、调测试、查依赖树，否则Too few arguments或Class not found会立刻报给你看。
怎么确认一个包真被废弃，且有官方推荐替代？
靠终端那行黄色警告不靠谱，它可能被 CI 日志折叠，也可能来自镜像缓存延迟。最准的是三步交叉验证：
- 运行
composer show vendor/package-name，重点看输出里有没有abandoned : true或replaced by : new/package——后者才是作者盖章的迁移路径 - 打开
https://packagist.org/packages/vendor/package-name，看右上角「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\并逐个替换成新前缀 - 检查新包是否有
"replaces": {"old/package": "^2.0"}字段——只有带这个才可能“无缝”，否则别假设兼容 - 特别注意
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 或闭源组件，且它们没提供新版，你就得权衡：是 fork 它们打 patch，还是自己封装一层适配器过渡
- 别信
composer outdated——它不展示abandoned状态；也别靠grep abandoned composer.lock找全貌，它只反映当前锁文件快照，漏掉未安装但已声明的废弃依赖
替换后必须验证的三件事
跑完composer update和composer dump-autoload -o只是开始，真正容易出问题的都在运行时：
- 单元测试必须覆盖该包的核心使用场景：比如日志包要看上下文传递、处理器链顺序、格式化器是否生效；HTTP 客户端要看重试逻辑、超时设置、错误码解析是否一致
- 执行
composer why vendor/old-package确认返回空——如果有输出，说明还有残留引用没清理干净 - 检查生产环境配置：有些废弃包的类名硬编码在 YAML 配置里（如 Symfony 的
monolog.handler.custom），这种不会报 PHP 错误，但日志会静默丢失
最麻烦的不是改代码，而是废弃包混在二级依赖里，等某天 PHP 升级到 8.4，它调用的一个反射方法被移除，才第一次暴露——那时再查，代价远高于现在花半小时理清依赖树。
