replace字段仅在依赖解析时生效，不删除、安装或修改autoload；需先执行composer remove guzzlehttp/guzzle才能使replace生效，否则声明被忽略。
replace字段只在依赖解析时起作用，不删包、不装包、不改autoload
加了 "replace": {"guzzlehttp/guzzle": "*"} 后 composer install 没反应？正常。replace 不是命令，它只是对 Composer 说：“如果某个包 require 了 guzzlehttp/guzzle，而我又被装上了，那你就别再装原版了”。它不会触发任何文件操作——旧包还在 vendor/ 里，新包也不会自动下载，autoload 更不会继承。
常见错误现象：
- 运行
composer install后guzzlehttp/guzzle依然存在 - 类报
Class not found，但命名空间和方法都对得上 - CI 环境部署失败，本地却能跑通
根本原因就一个：replace 是声明，不是动作。它只影响“要不要装”，不负责“怎么加载”或“删不删旧的”。
必须先 composer remove，否则 replace 彻底无效
想让 replace 生效，第一步永远是手动清理：运行 composer remove guzzlehttp/guzzle（或其他被替代包）。否则 Composer 会认为“原包已存在”，直接跳过解析环节，你的 replace 声明根本不会被读取。
还要注意依赖链：
- 用
composer show --tree | grep guzzlehttp/guzzle查有没有其他已安装包 still require 它 - 如果有，你得要么升级/修改那个包，要么在自己包里加
"conflict": {"guzzlehttp/guzzle": " 阻断兼容版本 - CI 或新机器重装时，只要某依赖仍 require 原包，它就会被拉回来——replace 不具备持久屏蔽能力
autoload 必须手抄，漏一个斜杠就 Class not found
replace 不继承原包的 autoload 配置。哪怕你完全复刻了 GuzzleHttp\Client 的代码，只要没在自己的 composer.json 里配好 "psr-4": {"GuzzleHttp\": "src/"}，运行时就崩。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操步骤：
- 查原包 autoload：
composer show -p guzzlehttp/guzzle，看它是psr-4、classmap还是files - 把输出里的整个 autoload 块完整复制进你自己的
composer.json，路径和命名空间一个字符都不能错 - 执行
composer dump-autoload -o，再用composer show -p确认映射已生效
最容易被忽略的是：原包用 "src/"，你写成 "./src/" 或 "src" —— Composer 不报错，但类就是找不到。
fork 场景别硬套 replace，该用 repositories + as + conflict
想用自己 fork 的 monolog/monolog 替换原版？直接在项目根 composer.json 里写 "replace": {"monolog/monolog": "*"} 是无效的。因为 replace 是包级元信息，只对你自己发布的那个包生效；你在项目里声明 replace，Composer 直接忽略。
正确做法是：
- 改 fork 包的
name字段，比如改成"yourname/monolog"（否则会报Package monolog/monolog is already registered） - 在项目根
composer.json加repositories指向你的 fork 地址 -
require写成"yourname/monolog": "dev-main as monolog/monolog" - 加
"conflict": {"monolog/monolog": "!"}防止原包混入
replace 的合理用途其实很窄：废弃子包合并、轻量 polyfill 内联、归档包兼容层。它不是通用替换工具，也不是 patch 机制——把它当“逻辑占位符”更准确。
