Composer 的 replace 字段仅在包被安装时声明替代关系，不自动卸载被替包或校验接口兼容性；需用 composer show --tree 和 why 定位冲突，手动移除冗余 require 并确保提供者完整实现契约。
当你的项目依赖某个 Composer 包 A，而 A 又依赖包 B，但包 B 已被另一个包 C 用 "replace" 声明替代（比如 "monolog/monolog": "2.0.0" 被 "monolog/monolog": {"replace": {"psr/log": "^1.0"}} 的包间接影响），实际安装时可能报错或行为异常。核心问题不是“不能装”，而是 Composer 在解析依赖图时发现版本冲突、提供关系不明确，或自动替换逻辑未按预期生效。
确认 replace 关系是否真正生效
Composer 的 replace 字段只在 包被安装时起作用：它告诉 Composer “如果我被装了，就当作那些被 replace 的包也存在了”。但它不会自动卸载或覆盖已存在的被替代包，也不会强制其他依赖去适配新包。
- 运行
composer show --tree查看实际解析出的依赖树，确认被 replace 的包（如psr/log）是否由预期的包（如monolog/monolog）提供 - 检查该“被替换包”是否仍作为独立依赖出现在
composer.lock或require中——如果有，Composer 会尝试同时装它和它的替代者，极易冲突 - 用
composer why psr/log（把psr/log换成实际被 replace 的包名）查谁在拉取它，定位源头依赖
手动移除冗余的被替换包声明
如果你的 composer.json 或某个依赖显式写了 "psr/log": "^1.0" 这类已被替代的包，Composer 就会坚持装它，哪怕已有包通过 replace 提供了相同功能。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 删掉项目根
composer.json中对被 replace 包的直接require - 如果某依赖（比如旧版
some/lib）硬依赖psr/log且不兼容新提供者，考虑升级那个依赖，或加"replace"到你自己的composer.json中临时兜底（慎用） - 执行
composer update --with-all-dependencies确保依赖图重算，让 replace 关系重新参与决策
检查提供者包是否真能替代（接口兼容性）
replace 是声明性的，不校验代码兼容性。例如 monolog/monolog 声明 replace psr/log，但只保证它实现了 Psr\Log\LoggerInterface；如果某依赖还用了 psr/log 的扩展接口（如 Psr\Log\LogLevel 常量），而提供者没包含这些，运行时仍可能出错。
- 查看被 replace 包的源码或文档，确认提供者是否完整实现其全部公开契约
- 如有疑问，可在
composer.json中保留被替换包的最小必要版本（如"psr/log": "^1.0 || ^2.0"），让 Composer 自动选一个可用实现 - 避免在
replace中写模糊版本（如"psr/log": "*"），应明确范围（如"^1.0"）
必要时用 provide + conflict 组合控制更精准
仅靠 replace 有时不够。比如你想确保项目里 只能有一个 PSR-3 实现，且必须是你指定的包：
- 在你自己的包中写：
"provide": {"psr/log": "^1.0"}（表明能力） - 同时写：
"conflict": {"psr/log": "=2.0"}（排除不兼容版本） - 再配合
"replace": {"psr/log": "^1.0"}（声明替代身份） - 这样 Composer 在安装时会拒绝任何与你冲突的
psr/log版本，强制使用你的提供者
基本上就这些。关键是理解 replace 不是魔法开关，它依赖 Composer 的依赖解析时机和整个图的一致性。动手前先 show 和 why，比盲目删锁文件更可靠。
