废弃包需验证确认：用composer show查abandoned状态，grep锁文件或查packagist页面；替换时须核对命名空间、参数等兼容性，并用composer depends --tree定位深层依赖，不可仅改包名。
看到 Package foo/bar is abandoned 警告，别急着删包或改 composer.json——Composer 不会替你做决定，它只报信；真正要动的，是你对依赖链的理解和迁移节奏。
怎么确认一个包真被废弃、该不该管
警告不是错误，但它是明确的风险信号：作者已停更，PHP 新版本、安全补丁、autoload 映射都可能随时失效。别靠眼睛扫日志，用命令验证：
-
composer show foo/bar看输出里是否有abandoned: true或replaced by: vendor/new-package；有后者就按它来，这是作者盖章的迁移路径 -
grep -A1 -B1 '"abandoned"' composer.lock查锁文件最准，绕过镜像缓存干扰（阿里云等常延迟同步废弃状态） - 如果
abandoned: true但没replaced by，说明作者没指定替代项，得自己查 Packagist 页面右上角「Replaced by」字段，或翻 GitHub README
替换时为什么不能只改包名
多数废弃包的替代者不只是换个名字，连命名空间、构造函数参数、返回类型都变了。比如 guzzlehttp/guzzle:^6 升到 ^7，GuzzleHttp\Client 的构造参数从 array $config 变成 HandlerStack $handler，直接换 require 条目，代码立刻崩。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先看新包的
autoload配置是否覆盖原路径；若新包用psr-4映射到不同根命名空间，就得批量改use语句 - 检查新包
composer.json里有没有replaces字段（如"replaces": {"old/package": "^1.0"}），这种才可能“无缝”替换 - 运行
composer dump-autoload -o后必须跑单元测试，尤其关注 HTTP 客户端、缓存、序列化等核心调用点
谁在偷偷拖后腿：如何定位深层废弃依赖
废弃包常藏在二级甚至三级依赖里，比如 some-vendor/sdk 的 composer.json 里硬写了 "old-org/legacy-helpers": "^1.0"。这时你直接 composer remove 会失败，因为上游没松口。
- 用
composer depends --tree foo/bar（Composer ≥2.4）看完整引用链；旧版本可用composer show -t foo/bar往上逐层推 -
composer why foo/bar只显示直接引用者，对 transitive 依赖不直观，容易漏掉 - 特别注意
require-dev里的废弃包，比如旧版phpunit/php-token-stream，看着不关键，但 CI 一跑就报Class not found
replace 字段不是自动重定向，别误用
"replace": {"old/package": "*"} 是你在自己维护的包里写的声明，意思是“装了我，就等于装了那个”，仅用于你可控的迁移场景（比如内部封装层）。它不改 autoload，不重写类名，也不影响第三方包。
- 你不能用它去“覆盖”别人发布的废弃包（比如想用
my-org/new-utils替掉monolog/monolog） - 如果上游包（如
some-vendor/sdk）仍硬依赖旧包，你的replace声明会被忽略 - 真正生效的前提是：接口基本兼容，且所有调用方都经过你控制或已适配
最麻烦的不是警告本身，而是废弃包混在某个你不常碰的 dev 工具链或子依赖里，等升级 PHP 或框架版本时才突然炸开。每次 composer update 后花两分钟跑 composer depends 和 composer audit，比修半夜的生产故障省力得多。
