composer show 默认不显示弃用信息，因为它仅读取包元数据而不触发依赖解析或 autoload 加载；真正暴露弃用状态需通过 composer update --dry-run -v 查看实时提示，或检查 composer.json 中的 replace/conflict 字段及 Packagist 页面的「Replaced by」权威标识。
composer show 为什么看不到弃用警告？
因为 composer show 只查包元数据，不触发依赖解析或加载 autoload，自然不会读取 composer.json 中的 replace、conflict 或 vendor 包里的 deprecation 提示。真正能暴露弃用信息的，是安装、更新或 dump-autoload 过程中 Composer 主动扫描的提示。
运行 composer update --dry-run 查看实时弃用提示
这是最直接有效的方式——它会模拟更新流程，加载所有已安装包的 autoloader，并触发 PHP 的 trigger_error(E_USER_DEPRECATED)（如果包在 autoload.php 或服务提供者里写了弃用逻辑），同时检查 composer.json 中的 replaced 和 conflict 字段。
- 执行
composer update --dry-run --verbose，留意输出里以 Deprecated: 开头的行 - 若某包被标记为
"replaced": {"old/package": "self.version"}，说明它已正式被替代，old/package通常就是该弃用包的官方替代方案 - 注意：有些弃用只在 PHP 运行时触发（比如 Laravel 的 facade 类），
--dry-run不会执行代码，这类提示需靠composer dump-autoload -o && php -d error_reporting=32767 -d display_errors=1 -r "require 'vendor/autoload.php';"手动触发
检查 vendor 目录下包的 composer.json 替代关系
很多包会在自己 composer.json 的 replace 或 provide 字段声明替代关系，这是最权威的“官方替代方案”来源。
- 定位到
vendor/old/package/composer.json，搜索"replace"或"conflict" - 常见模式：
"replace": {"laravel/framework": " 表示该包已整合进主框架；或 <code>"replace": {"monolog/monolog": "^2.0"}暗示应迁移到新版 - 若看到
"suggest"里有"phpunit/phpunit": "Use ^10.0 instead"，这虽非强制替代，但属于维护方明确推荐路径
用 composer why-not 精准定位阻塞升级的弃用包
当你想升级某个包却失败，又不确定是否因弃用导致兼容性中断，composer why-not 能揭示真实依赖链冲突点。
- 例如：想升级
symfony/console到 v6，但失败，运行composer why-not symfony/console:^6.0 - 输出可能显示：
myapp/mylib dev-main requires symfony/console (^5.4)，而myapp/mylib已被标记为abandoned，其composer.json中"replacement": "neworg/newcli" - 此时
neworg/newcli就是必须切换的官方替代方案——不是靠猜，而是 Composer 解析出的明确替换声明
replace/conflict、PHP 运行时触发的 E_USER_DEPRECATED、以及 packagist.org 页面上的人工标注。最容易被忽略的是第三种——别只盯着命令行输出，遇到模糊提示时，直接去 https://packagist.org/packages/old/package 看维护状态和推荐替代项，那里常有文档链接和迁移指南。 
