provide 字段用于声明本包可替代其他包，如实现相同接口的轻量替代品；必须写在需被下游依赖识别为兼容替代时，格式为 "provide": { "vendor/name": "version" }。
provide 字段是干啥的，什么情况下必须写
是
中用于声明“本包能替代其他包”的字段，本质是告诉 Composer：“我虽然不是
，但我实现了它的接口、能当它用”。常见于虚拟包（virtual package）或轻量实现（比如日志适配器、缓存驱动）。不写
，下游依赖
的包就无法安装你的替代实现——Composer 会报错：
provide 写法和 key-value 规则
格式固定为对象：
。注意：
必须是合法包名（如
、
），不能带空格或特殊字符
不是真实版本号，而是“兼容声明”：可写
（表示完全兼容）、
（语义化兼容）、甚至
（引用本包当前版本）
一个包可
多个包，但每个 key 必须唯一；重复声明同一名字会覆盖前一条
不能用
声明自己（即
是无效且无意义的）
示例：
provide 和 replace、conflict 的区别在哪
是“我能当谁用”，纯声明，不触发卸载；
是“我就是谁”，Composer 安装时会跳过被替换的包；
是“我和谁不能共存”。三者常组合使用：
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
想提供 PSR-3 实现又不想让
被实际安装？只写
+
自己的接口类即可
想彻底替代
并阻止它被装进来？加
担心旧版
的 API 冲突？补上
错误做法：只写
不写
——下游依赖
的包仍会失败，因为
不传递“能力”，只影响安装决策。
本地测试 provide 是否生效的最快方法
别等 CI 或别人反馈，用
直接验证：
先
（确保已发布或 path repo 配置正确）
再运行
，看到类似
就说明生效
如果报
，大概率是
字段没设成
（虽非强制，但强烈建议设）
真正容易被忽略的是 autoload 配置：即使
写对了，若没通过
暴露对应接口类（如
），运行时仍会
。
providecomposer.jsonmonolog/monologprovidemonolog/monologRoot composer.json requires monolog/monolog, but none of the packages provide it."provide": { "vendor/name": "version" }vendor/namepsr/logmonolog/monologversion*^1.0self.versionprovideprovide"provide": { "myorg/mylib": "*" }
"provide": {
"psr/log": "^1.0 || ^2.0",
"monolog/monolog": "*"
}
providereplaceconflictpsr/logproviderequiremonolog/monolog"replace": { "monolog/monolog": "*" }monolog"conflict": { "monolog/monolog": "replaceprovidepsr/logreplacecomposer show --treecomposer require your-virtual-package:dev-maincomposer show --tree | grep "psr/log"yourorg/psr-log-adapter 1.0.0 provides psr/log (^1.0 || ^2.0)your-virtual-package is not a valid virtual packagetypevirtual-packageprovideautoloadPsr\Log\LoggerInterfaceClass not found