Composer不会自动替换废弃包，仅警告；需手动确认替代项（查Packagist页面“Replaced by”字段、GitHub README或composer show输出），区分直接/子依赖并采取remove+require或升级父包策略，替换后须验证autoload映射、方法签名及行为一致性。
Composer 不会自动替换废弃包，只报 warning；你必须手动干预，否则迟早遇到 Class not found 或方法签名不兼容。
怎么确认废弃包有没有靠谱替代项
Composer 提示里的 Use xxx instead 只是同步了 Packagist 页面上维护者填的 replaced by 字段——这个字段可能为空、过时，甚至指向 psr/log 这类接口而非具体实现。
- 运行
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 会卡在依赖解析阶段，不是报错就是回退到旧版本。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先运行
composer depends vendor/old-package，确认谁在依赖它；若输出含root，说明是直接依赖 - 若是直接依赖：执行
composer remove vendor/old-package，再composer require vendor/new-package:^3.0（注意别照抄旧版约束，新包主版本可能不兼容） - 若是子依赖（比如被
aws/aws-sdk-php拉入）：不要删，应升级父包，composer update aws/aws-sdk-php，让它自己切换依赖链 - 父包长期不更新？可考虑 fork 后 patch 其
composer.json，或用conflict阻止旧包被拉入（风险高，慎用）
换完包为什么还报 Class not found 或方法参数错误
多数废弃包的替代者不只是改名，连 autoload 映射、命名空间、构造函数参数、返回类型都重构过。直接换包名几乎必然失败。
- 检查新包的
composer.json中autoload配置：是否仍映射到src/？命名空间前缀是否一致？不一致就得批量改use语句 - 验证方法签名是否一致：比如
GuzzleHttp\Client从 v6 升 v7，构造参数从array $config变成HandlerStack $handler - 运行
composer dump-autoload -o后必须跑单元测试，尤其验证日志写入、HTTP 请求、上下文传递等基础设施行为是否一致 - 检查新包是否声明了
"replaces": {"old/package": "^2.0"}；有这个字段才可能“无缝”，否则别假设兼容
怎么确认废弃包真被清干净了
别信自己眼睛，也别只看 composer.json 里删没删——残留常藏在锁文件、子依赖树或 autoload 缓存里。
- 执行
composer why vendor/old-package，如果还有输出，说明某个已安装包仍硬依赖它，得继续升级上游 - 运行
composer show --tree | grep old-package，确保没残留在子依赖里 - 检查
vendor/composer/autoload_classmap.php和autoload_psr4.php，确认旧类路径已消失 - CI 脚本里加
--fail-on-warning（Composer 2.5+ 支持），别让废弃警告被2>/dev/null吞掉
