provide 字段声明包提供的虚拟包（如 psr/log），使其他包可依赖抽象接口而非具体实现；它不触发安装，仅作能力声明，版本需匹配实际支持的契约，是 Composer 实现面向接口编程的关键机制。
provide 字段用于声明当前包“提供”了某个虚拟包（virtual package），让其他包可以依赖这个抽象接口，而不绑定具体实现。
解决接口与实现分离的问题
PHP 本身没有原生的接口级依赖机制。比如多个日志库（monolog/monolog、psr/log）都实现了 psr/log 接口，但 Composer 默认只认真实存在的包名。如果一个组件写 "requires": {"psr/log": "^1.0"}，会报错——因为 psr/log 是个规范包（含接口定义），不是可安装的实现。
这时，monolog/monolog 在自己的 composer.json 中写：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
"provide": {
"psr/log": "^1.0"
}
Composer 就知道：装了 monolog，就等于满足了对 psr/log 的依赖。其他包就能安全地声明依赖 psr/log，而不用指定必须用 monolog。
常见使用场景
-
PSR 规范实现：如
symfony/http-foundation提供psr/http-message-implementation，表明它实现了 PSR-7/17 等消息接口 -
驱动抽象：数据库驱动包（如
doctrine/dbal）可能提供pdo-extended-driver这类虚拟名，供 ORM 层统一依赖 -
插件系统兼容性：CMS 插件声明自己 “provide” 某个平台扩展点（如
wordpress/plugin-api-v2），主程序据此判断是否支持
注意点
- 不触发自动安装：provide 只是“声明能力”，不会让 Composer 去下载被提供的包（它本就不存在）
-
版本需合理匹配：提供的版本号应反映实际支持的接口契约范围，例如实现 PSR-3 v1.1.0 的库，应写
"psr/log": "^1.1"，而非"^1.0" - 不能替代 replace：replace 是用来替换另一个真实包（如 fork 替代原包），provide 是面向抽象概念的，二者语义不同
基本上就这些。provide 是 Composer 实现“面向接口编程”的关键桥梁，让包之间能解耦于具体实现。
