replace字段声明包逻辑替代关系，使依赖旧包的项目能安装新包，但需同步清理composer.lock中旧包条目并确保源配置正确。
composer.json 中的 replace 字段如何影响依赖解析
Composer 不会自动把一个包“重命名”后继续当作原包使用，它只认 vendor/name 这个完整标识符。如果你把 oldvendor/oldpackage 重命名为 newvendor/newpackage，旧包就彻底从依赖图中消失了——除非你显式声明 replace 关系。
replace 是 composer.json 的一个字段，作用是告诉 Composer：“我这个包逻辑上替代了另一个包”，从而让依赖该旧包的项目能继续安装成功。但它不改变包名本身，也不触发自动迁移或重定向下载。
- 必须在新包的
composer.json中写明："replace": {"oldvendor/oldpackage": "self.version"} - 旧包不能还存在于
require或require-dev中，否则 Composer 会尝试同时装两个冲突包 -
replace不会影响dist.url或source字段，新包仍走自己的源和发布地址 - 如果旧包已被其他包通过
require显式引用，而新包没加replace，Composer 就会报Could not find package oldvendor/oldpackage
为什么 composer install 会因重命名失败，即使 replace 已配置
常见现象是：你改了包名、加了 replace、更新了 composer.lock，但 CI 或同事运行 composer install 时仍失败，提示找不到旧包名。
根本原因不是 replace 没生效，而是 composer.lock 里还残留着对 oldvendor/oldpackage 的条目——Composer 在 install 阶段只按 lock 文件还原，不会重新解析 replace 关系。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须运行
composer update oldvendor/oldpackage或全量composer update，让 Composer 识别到该包已被新包replace，并从 lock 中移除旧条目 - 如果旧包已从 Packagist 或私有源下线，
composer update会直接失败，此时需先手动删掉 lock 文件中对应块（或整个 lock），再重跑composer update - 若项目里仍有代码
use oldvendor\oldpackage\SomeClass;，replace不解决运行时类名不匹配问题，需同步改命名空间和引用
replace 和 provide 的关键区别
很多人混淆 replace 和 provide，它们在依赖解析中行为完全不同：
-
replace：声明“我完全取代某个包”，Composer 会把它当做一个逻辑别名，在解析时剔除被替换包的所有依赖项；适用于包名变更、废弃迁移场景 -
provide：声明“我能提供某接口能力”，比如"psr/log-implementation": "1.0.0"，它不删除原包，只是满足某虚拟包（virtual package）的 require；常用于日志、缓存等标准实现 - 若你只想让新包被当作 PSR 标准实现来用，用
provide；若你想让所有依赖旧包的地方无缝切到新包，必须用replace并清理 lock
私有源中重命名包的典型陷阱
在 Satis 或 Private Packagist 环境中重命名包，最容易忽略的是源配置与 dist URL 的耦合性。
例如：旧包 acme/logger 发布在 https://packages.acme.com/acme/logger/1.0.0.zip，你新建了 acme/monolog-bridge 并加了 "replace": {"acme/logger": "self.version"}。但 composer.lock 里仍存着旧包的 dist.url，而新包的 ZIP 地址是 https://packages.acme.com/acme/monolog-bridge/1.0.0.zip ——这两个 URL 完全无关，Composer 不会自动跳转。
- 运行
composer update --with-all-dependencies前，先确认repositories配置里包含新包所在源，且顺序优先于旧源（避免缓存干扰） - 用
composer show acme/logger检查是否还能查到旧包；如果能，说明源还没切换干净，或者旧包仍在某个子依赖的require中漏掉了 - 最稳妥的做法：在团队内统一执行一次
composer update acme/logger --with-dependencies，而不是靠个人手动删 lock
重命名不是改个名字就完事，replace 是开关，lock 文件是状态快照，源配置是路径地图——三者缺一不可。最容易被跳过的，就是更新 lock 后没验证 composer show --tree 是否真把旧包清出了依赖树。
