Composer 的 provide 字段用于声明当前包提供某个虚拟包的能力，仅参与依赖解析而不安装代码，典型用途是解耦接口与实现，如多个日志实现包均 provide 同一接口名以支持“一个接口、多个实现”。
什么是 Composer 的 provide 字段？
provide 是 composer.json 中的一个可选字段，用于声明当前包“提供”了某个虚拟包（virtual package）的能力。它不安装任何实际代码，只在依赖解析阶段参与版本约束匹配。典型用途就是解耦接口与实现——比如多个包都实现了 psr/log 接口，但它们彼此不继承、不关联，靠 provide 告诉 Composer：“我满足这个契约”。
如何用 provide 实现“一个接口，多个实现”？
假设你定义了一个抽象日志接口包 myorg/logger-interface，而 myorg/file-logger 和 myorg/redis-logger 都实现了它。你不希望业务项目直接依赖具体实现，而是通过接口约束 + 运行时选择。这时：
-
myorg/logger-interface的composer.json不需要provide，它本身就是真实包 -
myorg/file-logger的composer.json加上：{ "name": "myorg/file-logger", "provide": { "myorg/logger-interface": "*" } } -
myorg/redis-logger同理，也provide相同的虚拟名 - 业务项目只需声明
"require": { "myorg/logger-interface": "^1.0" }—— Composer 就会允许任一提供该接口的实现被安装
常见错误：为什么 provide 不生效？
最常踩的坑是混淆了“提供者”和“消费者”的角色。关键点：
-
provide必须写在实现包里，不是接口包里 - 虚拟包名（如
"myorg/logger-interface"）必须和消费者require的名字完全一致，包括大小写和斜杠 - 如果接口包本身已发布为真实包（有代码、有版本），就不该再用
provide声明它自己；否则 Composer 会报Package myorg/logger-interface is not installed类似错误 -
provide不解决自动加载或运行时绑定，只是让composer install通过。DI 容器仍需手动配置哪个实现被注入
替代方案对比：replace 和 conflict 能不能用？
replace 是用来声明“我替代另一个包”，适用于 fork 替换原包；conflict 是禁止共存。它们都不适合接口多实现场景：
-
replace会让 Composer 卸载被替换的包，破坏契约意图 -
conflict只能排除，不能启用替代实现 - 只有
provide是专为“能力声明”设计的机制，且支持版本通配（如"*"或"^2.0"）
真正难的不是写 provide，而是设计好虚拟包名的粒度和生命周期——一旦发布，改名就会导致下游依赖解析失败。
