Composer不会自动替换废弃包，仅警告；需手动查Packagist「Replaced by」字段确认替代项，区分直接/子依赖（前者remove+require，后者升级父包），并验证autoload映射、方法签名及dev依赖。
Composer 不会自动替换废弃包，只报 warning；你必须手动确认替代项、区分依赖层级、验证 autoload 和方法签名，否则 Class not found 或 Too few arguments 会立刻出现。
怎么确认废弃包有没有靠谱替代项
别信终端那行黄色警告里的 Use xxx instead——它可能过时、为空，甚至指向 psr/log 这类接口而非具体实现。唯一权威来源是 Packagist 页面右上角的「Replaced by」字段。
- 运行
composer show vendor/package-name，看输出里是否有replaced by:行；若只有abandoned: true，说明没指定替代项 - 打开 https://www.php.cn/link/84ff7015cca989303244d13f1a8146fd，查右上角「Replaced by」——这是维护者亲手填的，比本地缓存准
- 若该字段为空，去 GitHub 仓库翻
README.md开头或UPGRADE.md，不是 Issues 里猜 - 注意 PHP 版本兼容性：比如
symfony/polyfill-php81替代某些废弃适配器，但你项目还在 PHP 7.4 就不能直接切
直接依赖 vs 子依赖，替换操作完全不同
硬删一个被上游包依赖的废弃包，Composer 会卡在依赖解析阶段，不是报错就是回退到旧版本。
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：若输出含root，说明是你自己require的；否则是传递依赖（比如被aws/aws-sdk-php拉入） - 若是直接依赖：执行
composer remove vendor/old-package，再composer require vendor/new-package:^3.0（别照抄旧版约束，新包主版本 API 可能断裂） - 若是子依赖：不要删，应升级父包，例如
composer update aws/aws-sdk-php，让它自己切换依赖链 - 父包长期不更新？可临时加
"replace": { "vendor/old-package": "*" }到你项目的composer.json，但这只是“告诉 Composer 假装它存在”，代码仍调用旧类——必须同步 patch 或 fork 修复
换完包为什么还报 Class not found 或方法参数错误
多数废弃包的替代者不只是改名，连 autoload 映射、命名空间、构造函数参数、返回类型都重构过。直接换包名几乎必然失败。
- 检查新包的
composer.json中autoload配置：是否仍映射到src/？命名空间前缀是否一致？不一致就得批量改use语句 - 验证方法签名是否一致：比如
GuzzleHttp\Client::__construct()在 v6 接收array $config，v7 改成HandlerStack $handler - 运行
composer dump-autoload -o后必须跑单元测试，尤其验证日志写入、HTTP 请求、上下文传递等基础设施行为是否一致 - 检查新包是否声明了
"replaces": {"vendor/old-package": "^2.0"}；有这个字段才可能“无缝”，否则别假设兼容 - 特别注意
autoload-dev里是否引用了废弃包的测试类（如Monolog\Test\TestCase），这类常被忽略导致phpunit直接失败
最麻烦的不是装不上，而是它悄悄混在某个二级依赖里——composer depends 必须跑，composer why 必须清，composer dump-autoload -o 必须做，否则 autoload 映射断裂比代码报错还难排查。
