应立即检查并替换弃用包，运行composer show --abandoned定位问题，用composer depends分析依赖链，通过composer prohibits排查版本冲突，替换后执行composer update --dry-run预览变更，并在CI中加入JSON格式的弃用包检测。
Composer 安装时提示 Package X is abandoned 怎么办
这不代表项目立刻崩，但说明维护者已停止更新，长期用有安全和兼容风险。关键不是“能不能用”，而是“还能撑多久”——尤其当它被你项目的主依赖间接拉入时，替换成本可能远高于手动改一行。
用 composer show --abandoned 找出所有弃用包
别靠肉眼扫 composer install 的警告流，那容易漏。这个命令只列出明确标记为 abandoned 的包，且会显示推荐替代项（如果有）：
composer show --abandoned
常见现象：输出为空 ≠ 没问题，有些包没填 abandoned 字段但实际已归档；有些则标了 abandoned 却没写替代包，得自己查 GitHub star 数、最近 commit 时间、Packagist 更新日期。
- 注意区分直接依赖和间接依赖：用
composer depends <package-name></package-name>查谁在拉它 - 如果包被多个依赖链引用，优先处理最上层的直接依赖，避免重复替换
- 某些“弃用”是误标——比如作者迁移到新命名空间但忘了更新 Packagist 元数据，这时要核对源码仓库是否真停更
composer require 替换时绕开版本冲突的实操要点
想换 monolog/monolog 为 php-logging/logging？别急着删再装。Composer 会校验依赖图，硬删可能触发 Root composer.json requires ... but it is not installable。
- 先运行
composer prohibits <old-package></old-package>看哪些包锁死了旧版本 - 若旧包被其他依赖强制要求（如
laravel/framework依赖特定symfony/console），得等上游升级，或临时用replace在composer.json中声明“我已接管” - 替换后务必跑
composer update --dry-run预览变更，重点看downgrading和removing行——意外降级核心组件很常见 - 有些替代包 API 不兼容，比如
guzzlehttp/guzzlev7 → v8 的Promise返回类型变化，得搜代码里then(和wait()调用点
CI/CD 流程里怎么防弃用包悄悄混入
靠人盯日志不现实。最轻量的拦截方式是在 composer install 后加检查：
composer show --abandoned --format=json | jq -e 'length == 0' >/dev/null || (echo "Abandoned packages detected" >&2; exit 1)
但要注意：
- CI 环境默认用
--no-ansi，composer show --abandoned输出格式可能变，建议加--format=json确保结构稳定 - 有些团队把弃用包列入白名单（比如老系统强依赖
doctrine/orm2.x），那就得用脚本过滤，别一刀切 fail - 真正难的是“半弃用”状态：包还在发 patch，但 PHP 8.3 已不兼容，这种不会被
--abandoned捕获，得结合composer validate和静态分析工具
弃用提示本身不报错，最容易被忽略的其实是那些没被任何命令显式列出的间接依赖——它们藏在 vendor/composer/installed.json 里，得写脚本深挖。
