不会。Composer update 仅按 composer.json 的 require 字段解析安装依赖，不自动替换废弃包；需手动执行 composer remove 旧包 + composer require 新包，并验证 autoload、命名空间及代码引用。
composer update 会自动替换废弃包吗
不会。Composer update 命令本身不执行任何包替换逻辑，它只按 composer.json 当前的 require 字段解析并安装依赖树。即使某个包在 Packagist 上标记了 abandoned: "new/package"，composer update 也不会删掉旧包、装上新包——它只负责“照声明办事”。你看到的黄色警告只是提示，不是动作。
真正起作用的是 composer remove + require 组合
手动替换废弃包的标准路径是两步操作，顺序不能颠倒：
- 先运行
composer remove vendor/old-package—— 它会从composer.json的require中删行，并卸载对应目录和 autoload 映射 - 再运行
composer require vendor/new-package:^3.0—— 注意版本约束要显式指定（比如^3.0），别用^latest或空版本，否则可能拉到破坏性大版本
如果旧包是间接依赖（比如被 aws/aws-sdk-php 拉入），remove 会失败并报错“Package is not installed”。此时应升级上游包：composer update aws/aws-sdk-php，让它的新版自动切换底层依赖。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
replace 字段不是用来“自动迁移”的
"replace": {"old/package": "*"} 是一个常见误解点。它只在你自己的 composer.json 里生效，作用是告诉 Composer：“这个旧包的功能我已内建或封装，别再装它”。但它不会触发自动安装新包，也不会改写代码里的 use 或方法调用。更关键的是：如果你没同步修改代码，运行时仍会因 Class not found 崩溃——因为 replace 不提供类映射或适配层。
执行后必须验证依赖是否清干净
替换完成后，立刻运行以下命令确认残留：
-
composer why vendor/old-package—— 若有输出，说明某处 still depends on it，得继续追查 -
composer dump-autoload -o—— 尤其当新旧包命名空间不同（如Monolog\Logger→Psr\Log\LoggerInterface），否则 autoload 映射断裂比语法错误更难定位 - 全局搜索项目中所有
use、new、class_exists等对旧类的引用，手动替换成新包的等效 API
最易被忽略的是 autoload 和命名空间变更——它们不会报错，但会让某些服务注册或事件监听静默失效，直到上线后才暴露。
