废弃包需手动替换，Composer仅提示不干预；确认替代项应查Packagist页面、GitHub文档及composer show输出；替换时按直接依赖或子依赖分情况处理，执行remove+require或升级父包，并验证autoload、方法签名与行为差异。
废弃包不会自动替换，Composer 只提示，不干预依赖解析逻辑——你必须手动处理，否则迟早遇到 Class not found 或 Declaration must be compatible with。
怎么确认废弃包的真实替代项
Composer 的警告里写的 “Use xxx instead” 不一定可靠，它只是同步了 Packagist 页面上维护者填的 replaced by 字段。但这个字段可能为空、过时，或指向一个 PSR 接口（如 psr/log）而非具体实现。
- 打开
https://packagist.org/packages/{vendor}/{package}（例如https://packagist.org/packages/guzzlehttp/ringphp），看右上角「Replaced by」是否明确写了包名 - 若为空，点进 GitHub 仓库，优先翻
README.md开头和UPGRADE.md，不是 Issues 或 Stack Overflow - 运行
composer show vendor/package-name，输出里若有replaced by:行，才是当前 Composer 解析到的权威推荐；若只有abandoned: true，就得自己评估 - 别忽略 PHP 版本兼容性：比如
symfony/polyfill-php81替代某些废弃适配器，但你项目还在 PHP 7.4 就不能直接切
替换时该用 composer require 还是改 composer.json
不存在 composer replace 命令，所谓“替换”本质是删旧加新+更新依赖树。但操作顺序和方式直接影响是否成功。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果该包在你项目的
composer.json中是直接require的，先执行composer remove vendor/old-package，再composer require vendor/new-package:^3.0（注意版本约束，别盲目照抄旧版号） - 如果它是子依赖（transitive dependency），比如被
aws/aws-sdk-php依赖，就不能硬删——得先升级那个父包：composer update aws/aws-sdk-php，让它自己切换依赖链 - 执行
composer update后，立刻跑composer why vendor/old-package，确保返回空；若还有输出，说明某处没清干净 - 别跳过
composer dump-autoload -o，尤其当新旧包命名空间不同（如从Monolog\Logger切到Psr\Log\LoggerInterface）时，autoload 映射断裂比代码报错还难排查
为什么换完包还会报错：autoload、签名、行为全变了
多数废弃包的替代者不只是改个名字，类路径、构造函数参数、返回类型、甚至默认行为都可能重构过。直接替换包名几乎必然炸。
- 检查新包的
composer.json中autoload配置：是否仍映射到src/？命名空间前缀是否一致？不一致就得批量改use语句 - 对比关键方法签名：比如
GuzzleHttp\Client::__construct()在 v6 是array $config，v7 要求HandlerStack $handler，不改调用方式必报错 - 留意行为差异：旧包可能默认启用重试，新包默认关闭；旧包日志上下文是数组，新包要求
array|Stringable——这些不会报语法错，但会让业务逻辑静默失效 - 运行单元测试前，先确认测试本身没硬编码旧类名；
class_exists('OldPackage\Foo')这种检测要同步更新
短期压警告 ≠ 风险消失，长期必须建立防控机制
用 "config": {"audit": {"ignore-abandoned": ["vendor/old"]}} 压提示，只是把警告藏起来，不影响实际风险。PHP 8.4 或下一次 composer update 可能直接让项目启动失败。
- CI 流程里加
composer outdated --format=json | jq -r '.packages[] | select(.abandoned) | .name'，有输出就 fail - 定期跑
composer audit（需 Composer ≥2.5），它会结合 FriendsOfPHP 数据库检测已知 CVE，比单看 abandoned 更准 - 锁文件
composer.lock才是最真实的状态源：grep -A1 -B1 '"abandoned"' composer.lock比终端日志更可靠，不受镜像缓存干扰 - 最易被忽略的一点：有些废弃包其实在
require-dev里（如phpunit/phpunit-mock-objects），它们已被 PHPUnit 主包内置，直接删掉即可，不用找替代
