composer show vendor/package 能查到废弃状态（abandoned字段）和官方推荐替代项（replaced by字段），若无replacement则需手动查packagist；配合composer depends可定位依赖层级，避免误删间接依赖。
看到“Package xxx is abandoned”警告，别删包、别屏蔽、别等它炸——先确认它是不是真在你的运行时路径里，再决定是换、是移、还是绕。
composer show vendor/package 能查到什么关键信息
这命令是定位废弃包最直接的入口。它不只告诉你abandoned: true，还会输出replaced by字段（如果作者填了）。这个字段比终端警告更全、更准，因为 Composer 安装时的提示可能被日志折叠或截断。
- 若输出含
replaced by: psr/log，说明它只是接口层，你实际用的可能是monolog/monolog或php-logging/logger，得看自己代码里 new 的是谁 - 若只有
abandoned: true，没 replacement，说明作者没指定替代项，得去 Packagist 页面手动查横幅推荐 - 若包名带
-deprecated或-eol（比如composer/package-versions-deprecated），基本可判定是官方已提供内置替代，不用找第三方
composer depends vendor/old-package 揭露真实依赖层级
很多废弃包不是你主动 require 的，而是被某个上游库拖进来的。不查清楚就硬删，composer update 会直接报 conflict。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
composer depends vendor/old-package，看输出第一行是不是你的项目名：如果是，说明它是直接依赖，可安全 remove + require 替代 - 如果第一行是
some/lib，那得先查composer show some/lib，看它最新版是否已切换依赖；没切的话，要么等它发版，要么考虑 fork 后 patch 它的composer.json - 特别注意
require-dev里的废弃包（如phpunit/phpunit-mock-objects）：PHPUnit 9+ 已把 mock 功能合并进主包，这类可以直接删，不需替代
替换时不能只改包名，还得盯三处断裂点
API 不兼容是废弃包迁移中最容易翻车的地方。新包和旧包类名、命名空间、方法签名、构造参数都可能不同，光换 composer.json 不够。
- 检查新包的
autoload配置：比如从"psr-4": {"Monolog\": "src/"}变成"psr-4": {"PhpLogging\": "src/"}，所有use MonologLogger都得重写 - 看新包是否声明
"replaces": {"old/package": "^1.0"}：有这个字段才可能零修改替换；没有就别假设兼容 - 运行
composer dump-autoload -o后，必须跑单元测试，重点覆盖该包参与的逻辑链——HTTP 请求、日志写入、序列化等场景最容易暴露问题
没官方替代时，怎么筛出靠谱的社区方案
当 Packagist 页面没写 Replaced by，也找不到作者迁移文档，就得靠数据判断哪个社区方案能接得住。
- 在 Packagist 搜索关键词（比如
promises），按Last updated排序，优先看近 3 个月内有 release 的包 - 点进 GitHub，看
Issues里有没有人提 “PHP 8.3 incompatibility” 或 “Guzzle 7.5+ conflict”，有这类问题的慎选 - 检查它的
composer.json中require字段：避免引入你环境不支持的扩展（如ext-uv）或 PHP 版本（如"php": "^8.2"而你还在跑 8.1） - 别信 star 数：一个包 star 10k 但 last commit 是 2023 年，不如一个 star 200 但上周刚 merge PR 的
真正麻烦的不是找不到替代包，而是那个废弃包被三个不同层级的库交叉引用，且其中两个库半年没更新。这种时候，replace 字段和轻量 patch 往往比强行升级更稳——但前提是，你已经确认它没被运行时调用。
