看到“package is abandoned”警告时，应先用composer show确认是否真被废弃及是否有replaced by推荐替代；再查packagist页面右上角“replaced by”字段；用composer depends定位依赖来源；替换时执行composer remove旧包、composer require新包，并检查命名空间、autoload路径与api变更。
看到“Package is abandoned”警告时该怎么做
这不是错误，只是 Composer 在告诉你：这个包的作者已经不维护了。它还会装、还能跑，但 PHP 升级、安全补丁、依赖冲突迟早会出问题。别点回车就忽略，也别立刻删包——先搞清三件事：composer show vendor/package 看是否真被标记为 abandoned，有没有 replaced by 字段；打开 https://packagist.org/packages/vendor/package 确认右上角「Replaced by」是否填写；用 composer depends vendor/package 查清楚是你的代码直接 require 的，还是被某个 SDK 悄悄拖进来的。
替换时改 composer.json 还是用 replace？
Composer 没有 composer replace 命令。所谓“replace”，是写在你自己包的 composer.json 里的一个字段，仅适用于你控制的封装层。比如你写了 my-org/new-utils，想让它替代 old-org/legacy-helpers，才加 "replace": { "old-org/legacy-helpers": "*" }。对第三方废弃包（比如 guzzle/guzzle3 或 phpunit/phpunit-mock-objects），这招无效。正确做法是：composer remove vendor/old-package，再 composer require vendor/new-package，然后手动改代码里所有 use 和调用点。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么换了包还报 Class not found？
废弃包的替代方案往往不只是换名字，而是重构了命名空间、autoload 路径或方法签名。常见坑：psr-4 映射从 "Old\Helper\": "src/" 变成 "New\Util\": "src/"，导致 use OldHelperThing 直接失效；新包删掉了旧包里的 Helper::do()，改成 NewUtil::run()；甚至有些替代包只提供接口（如 psr/log），实际要配一个实现（如 monolog/monolog）。建议步骤：composer require --dev phpstan/phpstan 扫描旧类名调用位置；建临时 LegacyAlias.php 用 class_alias() 或函数包装桥接；逐文件替换，别等全改完再测。
怎么确认废弃包真的被清干净了？
执行完 composer remove 和 composer require 后，别信自己眼睛。运行 composer why vendor/old-package，如果还有输出，说明某个已安装包仍硬依赖它，得升级那个上游包；再跑 composer show --tree | grep old-package，确保没残留在子依赖里；最后检查 vendor/composer/autoload_classmap.php 和 autoload_psr4.php，确认旧类路径已消失。最容易漏的是 require-dev 里的测试工具类，比如 phpunit/phpunit-mock-objects 被移除后，phpunit 自己的新版本可能已内置 mock 功能，但旧测试里还写着 Mockery::mock() 就会崩。
