composer why能查出废弃包的引入路径：运行composer why vendor/package-name可显示直接或间接依赖者，如guzzlehttp/guzzle 6.5.5 requires guzzlehttp/ringphp (^1.0)；输出为空则为手动引入或lock残留；多路径时优先处理顶层依赖。
composer why 能查出废弃包是谁拉进来的
直接运行 composer why vendor/package-name，就能看到哪个直接依赖（或间接依赖）把那个废弃包带进来的。比如 composer why guzzlehttp/ringphp 可能输出 guzzlehttp/guzzle 6.5.5 requires guzzlehttp/ringphp (^1.0) ——说明是 Guzzle 6 拉的，不是你手动 require 的。
这个命令比翻 composer.json 更准，因为很多废弃包是“被带进来的”，你根本没在自己文件里写过它。
- 如果输出为空，说明该包是手动 require 进来的，或者已被卸载但 lock 文件残留
- 如果输出显示多个路径，优先从最上层（你的项目直接依赖）开始处理，避免“修一个，崩三个”
- 注意：
composer why不会告诉你包是否废弃，只负责画依赖链；废弃状态得另查
grep -A1 -B1 '"abandoned"' composer.lock 是最可靠的废弃快照
composer.lock 里每条包记录都固化了当时解析到的 "abandoned" 字段值，不受镜像缓存影响。用 grep -A1 -B1 '"abandoned"' composer.lock 一眼就能扫出所有废弃项及其替代建议（如果有）。
例如输出：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
"name": "monolog/monolog", "version": "1.27.1", "abandoned": "psr/log"
说明该版本明确标记为废弃，推荐换用 psr/log ——但注意这只是接口规范，不是实现包，你还得选一个具体实现（如 monolog/monolog 2.x 或 symfony/debug）。
- 镜像源（如阿里云）可能延迟同步 Packagist 的废弃标记，所以别信终端黄色警告是否出现，以 lock 文件为准
- 如果
"abandoned": true且无字符串值，代表作者没填替代方案，得自己评估 - 改完依赖后记得重新
composer update --lock，否则 lock 文件不会更新废弃字段快照
替换时命名空间、方法签名、autoload 配置三处最容易断裂
光执行 composer require new/vendor 和删掉旧包，90% 的项目会立刻报错。真正要动的是代码里那些耦合点：
- 全局搜索
use Old\Namespace\和new Old\Namespace\，替换成新包的命名空间（比如从use GuzzleHttp\Ring\Client切到use GuzzleHttp\Client） - 检查关键方法调用：新包可能把
$client->send($request, $options)改成$client->send($request, ['timeout' => 30])，参数类型、默认值、返回类型都可能变 - 确认 autoload 配置：旧包用 PSR-0，新包只注册 PSR-4 且根命名空间不同，
composer dump-autoload -o后必须跑单元测试或至少启动服务，否则Class not found错误只在运行时爆发
间接依赖的废弃包删不掉？先锁死再定向升级
当你发现 composer why 显示某个废弃包是被 some/lib 2.3 拉进来的，而你又不能直接升级 some/lib（比如它和你的 Laravel 版本冲突），就得用“锁死 + 替代”策略：
- 在
composer.json的require里显式加一行："abandoned-package/name": "^1.0"，然后composer update abandoned-package/name --with-dependencies，强制 Composer 重新计算路径 - 更稳妥的是用
replace字段：在composer.json里加"replace": {"abandoned-package/name": "*"}，再composer update，让 Composer 认为它已被“逻辑替代”，从而绕过安装 - 终极手段：用
composer prohibits abandoned-package/name查清谁在坚持拉它，然后给上游提 issue 或 fork 修复其 composer.json
这类问题往往卡在“别人没升级，你升不了”，这时候别硬刚版本号，重点是把运行时行为兜住——废弃包的类名、接口、行为边界，才是你真正要对齐的契约。
