Composer 不会自动替换已弃用包，仅警告；需手动确认替代项（查 composer show、Packagist 页面或 GitHub），区分直接/子依赖并采取不同替换策略，替换后须检查 autoload、方法签名及 dev 依赖。
遇到 Composer 提示 Package foo/bar is abandoned 时，可别指望它能帮你自动搞定。这个警告只是提醒，真正的替换动作必须由你手动完成。如果放任不管，项目迟早会出问题——无论是类找不到、方法签名不匹配，还是 PHP 版本兼容性错误，都可能让应用突然崩溃。
怎么确认废弃包有没有官方推荐替代项
Composer 提示里那句 Use xxx instead，其实只是同步了 Packagist 页面上维护者填写的 replaced by 字段。这个信息未必可靠，它可能为空、已经过时，甚至可能只指向一个 PSR 接口（比如 psr/log）而非具体的实现包。
- 先运行
composer show vendor/package-name，看看输出里有没有replaced by:这一行。如果只有abandoned: true，那就说明官方没指定替代项。 - 最权威的做法是直接打开
https://packagist.org/packages/vendor/package-name，查看页面右上角的「Replaced by」字段。 - 如果 Packagist 上也是空的，那就得去 GitHub 仓库翻一翻了。重点看看 README.md 的开头部分，或者在 Issues 里搜索
migration、replaced、deprecated这类关键词。 - 这里有个细节需要注意：有些包被废弃，是因为其功能被纳入了 PSR 标准。比如
monolog/monolog可能建议转向psr/log。但psr/log只是个接口规范，你仍然需要选择一个具体的实现包（比如php-logging/logger），或者干脆将monolog/monolog升级到兼容的新版本。
直接依赖 vs 子依赖，替换策略完全不同
处理废弃包，首先要搞清楚它是你的“直接依赖”还是“子依赖”。这两者的处理方式截然不同。如果是你自己在 composer.json 的 require 里明确引入的包，操作起来相对自由；但如果它是其他已安装包（例如 aws/aws-sdk-php）的传递依赖，强行删除可能会引发 Composer 的依赖冲突。
- 第一步，用命令
composer depends vendor/old-package来确认是谁依赖了它。如果输出结果里包含root，说明它是直接依赖；否则就是传递依赖。 - 如果是直接依赖：操作就简单了。先执行
composer remove vendor/old-package移除旧包，再用composer require vendor/new-package:^3.0引入新包。注意，别直接照抄旧版本的版本约束，新包的主版本号很可能已经不兼容了。 - 如果是子依赖：切记不要直接删除它。正确的做法是升级那个引入它的“父包”，比如运行
composer update aws/aws-sdk-php，让父包自己去切换使用的新依赖。否则，Composer 的依赖解析器很可能会卡住。 - 万一父包长期不更新怎么办？可以考虑 Fork 它的仓库，然后 Patch 它的
composer.json文件。或者，在你自己项目的composer.json里用conflict字段阻止旧包被拉入。不过后一种方法风险较高，需要谨慎使用。
替换后最常踩的三个坑
很多废弃包的替代者并非简单的改名，往往伴随着重构——自动加载映射、命名空间甚至构造函数参数都可能发生变化。如果只是换个包名就跑测试，失败的概率相当高。
- 务必检查新包的
autoload配置。举个例子，如果旧包使用psr-0映射Old_Helper_这样的类前缀，而新包改用psr-4映射Vendor\New\这样的命名空间，那么项目中所有相关的use语句和new实例化代码都需要批量修改。 - 必须验证方法签名是否一致。比如，
GuzzleHttpClient::__construct()在 v6 版本接收一个数组作为参数，到了 v7 版本可能就改为接收一个HandlerStack实例了。调用代码不跟着改，必然导致致命错误。 - 别忘了
autoload-dev。废弃包中的一些测试工具类（例如phpunit/phpunit-mock-objects）常常只出现在require-dev依赖里。替换主包后，运行phpunit时可能会因为找不到这些测试类而报错。
说实话，最麻烦的情况不是找不到替代包，而是这个废弃包深藏在二级甚至三级依赖里，并且它的接口断裂点分散在项目十几处不同的调用位置。面对这种情况，建议先使用 phpstan/phpstan 这类静态分析工具扫描所有对旧类名的引用，然后建立一个轻量的兼容层进行过渡。指望一次替换就能全部生效，往往不太现实。
