replaces 不能真正替换已安装包，仅在依赖解析时声明提供关系；需先 composer remove 旧包，新包配置 replaces 和 conflict，并确保所有依赖升级支持。
replaces 不能真正“替换”已安装的包
Composer 的 replaces 字段只在依赖解析阶段起作用，它不会卸载旧包、也不会重写已安装的文件。如果你已经装了 old-vendor/package，再声明一个新包用 replaces 去“覆盖”，Composer 会报错或静默忽略——除非旧包本身被其他依赖间接引入且未显式 require。
- 真实场景：你想用
new-org/core替代项目里所有对legacy/core的引用 - 必须前提：
legacy/core没有被require在composer.json顶层，否则 Composer 会坚持保留它 - 常见错误现象：
Your requirements could not be resolved to an installable set of packages，尤其当两个包提供相同命名空间但类定义冲突时 - 根本原因：
replaces是“声明我提供了你想要的东西”，不是“请删掉他换我来”
正确做法：先移除旧包，再用 replaces 引导后续依赖
要让 replaces 发挥作用，得主动清理旧包，并确保所有下游依赖都转向新包。这不是一步命令能完成的事，而是三步协同：
- 运行
composer remove legacy/core（不是require新包之前） - 在新包的
composer.json中明确写："replaces": {"legacy/core": "^2.0"}，版本号需覆盖旧包实际使用范围 - 所有原本 require
legacy/core的其他包，必须升级到支持新包替代的版本（即它们的require列表里改成了new-org/core或用了conflict+replace组合） - 否则，即使你本地删了旧包，CI 或新环境执行
composer install仍可能拉下旧包——因为某个未更新的依赖还在硬 require 它
replaces + conflict 是安全迁移的最小必要组合
单独用 replaces 风险极高，容易导致类加载冲突或版本错乱。生产级替换必须加 conflict 锁死旧包共存可能：
"conflict": {"legacy/core": " 表示：只要旧包版本低于 2.5.0，就拒绝安装当前包- 这个组合强制 Composer 在解析时排除旧包的任何兼容版本，避免“两个包同时存在、同名类重复定义”的致命错误
- 注意
conflict版本范围要足够宽，覆盖项目中实际使用的旧包版本；查法：composer show legacy/core - 性能影响几乎为零，但兼容性上：Composer 1.10+ 才完整支持
conflict与replaces联动校验
替换后 autoloading 冲突怎么查？
即使 replaces 和 conflict 都配对了，仍可能出现 Class not found 或 Cannot declare class X, because the name is already in use。核心排查点就两个：
- 检查
vendor/composer/autoload_psr4.php：确认旧包的命名空间映射是否还残留（说明它没被彻底卸载） - 运行
composer dump-autoload -o后，用grep -r "legacy\core" vendor/composer/看是否还有旧包的 autoload 条目 - 如果新包用了和旧包完全相同的命名空间（如都是
LegacyCore*），必须确保新包的autoload配置路径正确，且没有和旧包残余路径重叠 - 最隐蔽的坑：某些包在
install时执行脚本（scripts），偷偷注册了额外 autoloader，这类逻辑不会被replaces影响，得手动清理
