你或许遇到过这样的场景：在 composer.json 里加了 replace 字段，以为万事大吉，结果旧包还在那里，类加载失败，甚至依赖冲突。这到底是怎么回事？
replace 字段不会自动帮你卸下旧包袱，这一点必须牢记。 它的作用，仅限于在 composer install 或 composer update 解析依赖图时，告诉 Composer：“这个包我已经搞定了，不用再装一遍。” 它既不会重定向类加载，也不会覆盖任何文件——它只是一个声明，一个承诺。
replace 不会帮你删掉已安装的包
不少人在 composer.json 里加上 "replace": {"old-vendor/package": "*"} 后，就等着 composer install 自动清理。结果呢？old-vendor/package 依然稳稳地躺在 vendor/ 目录里，纹丝不动。Composer 不会也没义务替你执行删除操作。
- 你必须手动运行
composer remove old-vendor/package，这一步没法跳过，也不是 Composer 的职责。 - 如果这个旧包被其他依赖（比如
some-tool）硬性require，那下次 CI 或新机器上执行composer install时，它还是会卷土重来。 - 想知道它是不是被谁依赖着？运行
composer show --tree | grep old-vendor/package一查便知。
replace 后类找不到？autoload 没继承，得自己配
另一个常见陷阱：Composer 不会把被替换包的 autoload 配置自动复制到你包里。你声明替换了 acme/legacy-utils，但它的 autoload 用的是 "psr-4": {"Acme\": "src/"}，而你的包用的是 "MyOrg\" 命名空间，运行时就会报 Class not found。
- 先查清楚原包的 autoload 配置：运行
composer show -p acme/legacy-utils，看看它是psr-4、classmap还是files。 - 在你自己的
composer.json中完整复现相同的映射，哪怕只是把命名空间 alias 一下，也得做到位。 - 改完之后，务必执行
composer dump-autoload -o，再用composer show -p确认规则已经生效。
为什么加了 replace 还报冲突？conflict 得配齐
replace 声明的是“我顶替它”，但它并不阻止别人继续 require 这个包。如果某个依赖仍然明确写着 "old-vendor/package": "^1.2"，而你的包没有声明兼容版本或没有加 conflict，Composer 就会在依赖解析阶段卡住，直接报错。
- 必须在
replace同级加上"conflict": {"old-vendor/package": "*"}，用强约束来明确两者的共存关系。 - 版本约束也要对齐：如果原包只支持
^1.0，你写"replace": {"old-vendor/package": "*"}可能会导致解析失败。更稳妥的做法是写成"^1.0 || ^1.1"。 - 如果有多个包同时 replace 同一个包，Composer 会直接报错：
Package old-vendor/package is replaced by ... and ...，这种情况只能人工干预解决。
replace 不是 provide，别拿它去“实现接口”
想用自定义日志包替代 psr/log？写 "replace": {"psr/log": "*"} 是典型的错误用法。这会让 Composer 认为你“就是 psr/log 包本身”，但 psr/log 是一个虚拟规范包，没有实际代码——结果就是依赖图崩掉，autoload 也无从谈起。
- 实现接口应该用
provide：比如"provide": {"psr/log-implementation": "^1.0 || ^2.0"}。 replace只用于替换具体包：目标是真实存在、有源码、有 autoload 的包，比如monolog/monolog、symfony/polyfill-mbstring。- 两者可以共存：一个 fork 包既可以
provide接口能力，又可以replace原包，但语义不能混淆。
说到底，replace 生效的前提是你已经移除了旧包，并且你的代码真的提供了全部 public API——它不校验功能，只校验包名和版本声明。运行时报错，从来不是 replace 没生效，而是你没配全 autoload 或漏写了 conflict。
