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 不生效？

最常踩的坑是混淆了“提供者”和“消费者”的角色。关键点：

dmap-jsapi-skill

DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。

下载

• 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，而是设计好虚拟包名的粒度和生命周期——一旦发布，改名就会导致下游依赖解析失败。