replace用于彻底替换某包（如"psr/log": "^2.0 || ^3.0"），阻止其安装；provide仅声明接口能力（如"psr/log-implementation": "*"），不阻止同名包被require，易引发类冲突。
Composer 虚拟包（virtual package）不是真实发布的包，而是通过 replace 或 provide 声明“我已具备某能力”，从而阻止 Composer 安装重复实现——这是企业沉淀代码资产、收敛技术栈的关键手段，但用错会直接导致类加载失败或依赖解析混乱。
什么时候该用 replace 而不是 provide
replace 是“我替换了你”，Composer 会彻底跳过被替换包的安装；provide 是“我能提供这个接口”，但不阻止别人 require 同名包，容易引发冲突。
- 用
replace：企业自研了完整兼容psr/log的日志组件，且所有项目都强制使用它 —— 在根composer.json中写"replace": {"psr/log": "3.0.0"}，就能确保全量项目不装官方psr/log包 - 别用
provide替代replace：比如只在某个私有包里加"provide": {"psr/simple-cache": "3.0.0"}，其他项目仍可能require "psr/simple-cache"，结果同时存在两套实现，autoload 映射打架 - 注意版本号必须精确匹配：若上游要求
^2.0，而你replace的是"psr/log": "3.0.0"，Composer 仍会报错“无法满足约束”，得写成"psr/log": "^2.0 || ^3.0"
replace 必须和 autoload 映射对齐，否则类找不到
虚拟包不提供文件，它只是告诉 Composer “不用装了”，但实际类还得从你自己的代码里加载。所以你声明 replace 的同时，必须确保对应命名空间已通过 PSR-4 或 classmap 正确注册。
- 例如你
replace "monolog/monolog"，就得在composer.json的"autoload": {"psr-4": {"Monolog\": "src/Monolog/"}}中映射好路径，且src/Monolog/Logger.php真实存在、namespace 正确 - 常见错误：只改了
replace，忘了在autoload里补上Monolog\映射，运行时直接Class 'MonologLogger' not found - 验证方式：执行
composer dump-autoload -o后，检查vendor/composer/autoload_psr4.php里是否有对应前缀条目
企业级 replace 清单应集中管理，不能散落在各项目
每个项目自己写 replace，很快就会出现版本不一致、遗漏、冲突。企业应把核心虚拟包声明抽成统一基线配置。
- 新建一个私有基础包（如
acme/php-baseline），其composer.json只含replace和autoload，不带业务逻辑 - 所有项目
require "acme/php-baseline"，并设"minimum-stability": "stable"，避免开发分支污染 - 升级虚拟包能力时，只发新版
acme/php-baseline，团队执行composer update acme/php-baseline即可批量同步 - CI 流程中加检查：
composer show --tree | grep "psr/log"，确认输出为空，防止漏 replace
真正难的不是写 replace，而是让所有开发者理解：虚拟包不等于“删掉依赖”，它只是把实现权收归己有——配套的 autoload、测试覆盖、文档说明，缺一不可。一旦某天想切回官方包，没留退路的 replace 就会变成硬编码依赖。
