composer中不存在“虚拟包”概念，provide声明仅为逻辑占位符，不参与安装流程，不能通过vcs发布；正确做法是在项目require中直接声明ext依赖，或在真实库包中用provide解决替代实现。
Composer 里没有“虚拟包”这个官方概念，所谓虚拟包（如 ext-redis、php >=8.1）本质是 provide 声明的逻辑占位符，不能也不应该通过 VCS 发布——它不包含代码，不走 require 安装流程，更不会被 composer install 下载到 vendor。
为什么不能把 provide 包当 VCS 包发布
你可能遇到的情况是：想用一个空仓库“模拟”某个扩展或平台能力（比如声明自己 “提供 redis 扩展”），然后推到 GitHub 上让别人 require。这行不通，原因很直接：
-
provide字段只在已安装的包中起作用，用于满足其他包的require约束，它本身不是可安装实体 - VCS 仓库必须有真实
composer.json+ 可解析的版本（tag/branch），而仅靠"provide": {"ext-redis": ">=5.3.0"}的仓库无法被 Composer 识别为有效包源 - 即使强行注册为
vcs类型，运行composer require your-vendor/virtual-ext-redis时会报Could not find package ... in a version matching ...—— 因为没有实际版本可供解析
真正需要“虚拟能力声明”的正确做法
如果你的目标是让项目能通过 Composer 声明对某扩展或环境的依赖（例如强制要求部署机装了 ext-gd），应该在你自己项目的composer.json 中直接写：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
{
"require": {
"php": ">=8.2",
"ext-gd": "*"
},
"provide": {
"ext-gd": "8.2.0"
}
}
注意：provide 放在项目根 composer.json 里是无效的；它只应在被 require 的库包中声明，且只为解决冲突或替代实现（如用 symfony/polyfill-iconv 提供 ext-iconv）。常见误用场景包括：
- 试图用一个空 Git 仓库“欺骗” Composer 认为某扩展已存在 → 实际会失败，且 CI/CD 构建时暴露环境缺失问题
- 把
provide当作 feature flag 或配置开关 → 应改用条件加载、运行时检测或环境变量 - 希望私有包对外“隐藏实现但暴露能力” → 正确方式是发布真实包，在其
composer.json中provide对应接口，而非造虚拟包
VCS 仓库能发布的只有真实可安装包
如果你真有一个 PHP 库要发布，哪怕它只有一行 return true;，也必须满足：
- Git 仓库含有效的
composer.json，name格式为vendor/name - 至少打一个语义化 tag（如
v1.0.0），VCS 版本完全由 tag/branch 名驱动，version字段会被忽略 - 若需私有访问，
repositories中声明"type": "vcs"，URL 必须可 clone（HTTPS+token 或 SSH+key） - 本地开发调试可用
"type": "path"，但上线前必须切回 VCS 源，否则 Packagist 无法抓取
别绕开这些约束去“造虚拟包”，否则你会在 composer update 卡住、CI 报 no matching package found、或者上线后发现 vendor 目录空空如也。
