最准方式是用 composer audit --abandoned，它只读 composer.lock 和 packagist 元数据中的 abandoned 字段，输出明确简洁；composer show 默认不显示该字段，须加 -a 参数或结合 grep 查锁文件才能准确验证。
直接用 composer audit --abandoned，这是 Composer 2.2+ 内置、最准也最轻量的检测方式。它不联网查漏洞库，只读 composer.lock 和 Packagist 元数据里的 abandoned 字段，输出干净明确——没这一步，其他操作全是盲猜。
为什么 composer show 默认不显示废弃信息？
composer show vendor/package 默认压根不展示 abandoned 字段，哪怕包已被 Packagist 明确标记为废弃。很多人扫完就以为“没问题”，其实是信息根本没露出来。
必须加 -a（小写，不是 --all）：composer show -a vendor/package 才会输出 abandoned : true 或 abandoned : psr/log 这类关键字段。
- 若返回
abandoned : null，按 Packagist v2 协议，这也代表明确废弃 - 终端那行黄色警告可能来自镜像缓存或旧元数据，不可靠；
composer show -a+grep -A1 -B1 '"abandoned"'查composer.lock才稳 - 某些镜像（如阿里云）甚至不转发
abandoned字段，composer install根本不报 warning
composer audit --abandoned 的真实行为和干扰点
这个命令只做三件事：检查 composer.lock 中每个包是否在 Packagist 上被标记为废弃、是否配置了替代包、是否被本地 config.ignore-abandoned 显式忽略。输出每行一条结论：
-
vendor/old-package is abandoned, use vendor/new-package instead—— 有官方推荐替代，可立刻跟进 -
vendor/legacy-helper is abandoned, no replacement provided—— 作者没填替代项，得自己评估 fork 或重写 - 完全没输出？别高兴太早：检查是否配置了
config.ignore-abandoned，它会静默屏蔽警告 - 该命令不受镜像缓存干扰（比如腾讯云同步延迟），比肉眼扫
composer install输出靠谱得多
如何定位废弃包藏在哪一层依赖里？
废弃包常躲在二级、三级依赖中，比如 some-sdk 的 composer.json 里硬写了 "old-org/utils": "^1.0"。你直接删它会失败，因为上游没松口。
- Composer 2.4+：运行
composer depends --tree vendor/old-package，打出从根依赖到该包的完整引用链 - 旧版本：用
composer show -t vendor/old-package查依赖路径，再逐层往上推 - 特别注意
require-dev里的废弃包，比如phpunit/php-token-stream看似无关紧要，但 CI 一跑就报错 - 不查清楚层级就动手，很容易改了
composer.json却发现composer update报依赖冲突
镜像缓存会让废弃提示失效，怎么绕过？
镜像（如阿里云、腾讯云）会缓存元数据，导致 composer show 输出的 abandoned: true 是过期的。你看到的黄色警告可能来自上周的缓存，而 Packagist 上维护者昨天刚填了新替代项。
- 手动访问
https://packagist.org/packages/vendor/package-name，看右上角「Replaced by」字段——这是作者亲手填的，不是镜像生成的 - 需要临时禁用镜像查原始数据？加
--no-cache参数：composer show --no-cache vendor/package - 运行
composer clear-cache后再执行composer show，避免本地缓存干扰 - 有些镜像不转发
abandoned字段，composer install根本不报 warning——你以为没废弃，其实早被作者归档了
真正麻烦的不是找不到废弃包，而是它混在某个二级依赖里，且 autoload 映射、命名空间、方法签名全变了。这时候光看 replaced by 不够，得打开 GitHub 仓库翻 UPGRADE.md 或 SECURITY.md，而不是在 Issues 里猜。
