provide声明包实现某接口规范（如PSR-4），供Composer识别为替代品而不安装原包；replace则彻底移除被替换包及其依赖、autoload和脚本，两者可共存但语义与触发时机不同。
provide 是声明“我提供了某个包的能力”
当你的包实现了某接口规范（比如 PSR-4、PSR-16），但又不想直接依赖原包，就可以用 provide 告诉 Composer：“我虽然没 require psr/log，但我自己实现了它的全部契约”。Composer 会把它当作已安装的替代品，跳过真实安装。
常见使用场景包括：
- 自研日志实现，想兼容所有依赖
psr/log的库，但不引入 Monolog - 框架封装层提供标准缓存接口，实际底层是自定义驱动
- 发布一个“无依赖”的轻量包，却需满足生态兼容性要求
注意：provide 不会自动加载类，也不影响 autoloading 配置；它只参与依赖解析阶段的包可用性判断。版本号必须严格匹配（如 "psr/log": "^1.0"），否则其他包仍会尝试安装原版。
replace 是声明“我彻底替代某个包”
replace 的作用更激进：它让 Composer 认为被替换的包“已经不存在”，连带其所有依赖、autoload 和脚本都会被忽略。典型例子是 Laravel 的 laravel/framework 在 composer.json 中 "replace": {"symfony/http-foundation": "^5.4"} —— 表示它内部已打包并修改了该组件，不允许外部再装同版本。
关键行为包括：
- 被 replace 的包不会被安装，即使其他依赖显式 require 它
- 如果多个包 replace 同一个包，Composer 会报错（冲突）
- replace 的版本范围可以比原包宽泛，但不能窄于其实际提供能力
误用风险高：比如错误地 "replace": {"monolog/monolog": "^2.0"} 却没真正包含全部类和功能，会导致运行时报 Class not found。
provide 和 replace 同时出现时会发生什么
两者可共存，但语义不同、触发时机不同。例如：
{
"name": "myorg/cache-adapter",
"provide": {
"psr/cache": "^1.0",
"psr/simple-cache": "^1.0"
},
"replace": {
"doctrine/cache": "^1.11"
}
}
这段配置表示：
- 本包对外提供 PSR 缓存标准能力（供其他包在 require 时被识别为满足条件）
- 同时声明彻底替代
doctrine/cache，阻止它被安装
Composer 先处理 replace（移除冲突包），再基于 provide 解析依赖图。所以如果你 replace 了一个包，又 provide 它的接口，其实是“用新实现覆盖旧包 + 对外暴露契约”的完整方案。
容易踩的坑：版本写错、autoload 没配、测试不覆盖
最常被忽略的是三件事：
-
provide版本号写成"^2.0"，但实际只实现了 PSR-16 的部分方法，而下游包用了新增的getMultiple()—— 运行时报错，但 Composer 不报错 - 用了
replace却没在autoload里映射被替代包的命名空间，导致类加载失败 - 本地开发时手动删了被 replace 的包，CI 环境却因缓存或 lock 文件残留导致行为不一致
验证方式很简单：删掉 vendor 和 composer.lock，执行 composer install --no-dev，再检查 vendor/composer/installed.json 里是否真没出现被 replace 的包名，以及 composer show psr/cache 是否能列出你的包。
