虚拟包不能写 version 字段，因其无真实源码和 composer.json；仅支持语义化版本约束如 "^8.1" 或稳定性标识，Composer 依此检测环境是否满足。
虚拟包不能写 version 字段
Composer 虚拟包（如 ext-curl、php、lib-icu）根本不是真实发布的包，它没有源码、没有 composer.json、也没有 Git tag。因此你在 require 或 conflict 里声明它时，不能也不该给它设 "version" 字段——这个字段只属于真实包的 composer.json，对虚拟包毫无意义。
常见错误是试图在根项目 composer.json 中手动加一个虚拟包的 "version"，比如：
{
"require": {
"ext-gd": "8.1.0"
}
}这不会生效，Composer 会忽略该值，转而检查当前 PHP 环境是否满足 ext-gd 的实际可用性（即是否已加载、版本是否 ≥ 所需）。
虚拟包的版本约束只能用语义化范围或稳定性标识
你唯一能写的，是符合 Composer 解析规则的约束字符串，且必须对应其底层检测逻辑：
-
"ext-gd": "^8.1"→ 表示需要 GD 扩展，且 PHP 版本 ≥ 8.1（注意：这里不是 GD 自身版本，而是 PHP 主版本） "php": ">=8.1.0 → 合法，Composer 会校验运行时 PHP 版本-
"lib-icu": "~72.1"→ 合法，Composer 会调用icu_version()或系统命令检测 ICU 库版本 -
"ext-mbstring": "*"→ 合法，表示“只要存在即可”，不校验版本 -
"ext-redis": "dev-master"→ 非法，虚拟包不支持分支、别名或@dev标记
关键点在于：这些约束不是“安装”用的，而是运行时环境检查的断言。Composer 在 install 或 update 阶段会执行检测，失败则报错，例如：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
Your requirements could not be resolved to an installable set of packages. - Root composer.json requires ext-gd ^8.2, but it is missing from your system.
为什么 ^ 和 ~ 对虚拟包行为不同
因为虚拟包没有发布历史，Composer 不走 Packagist 解析流程，而是直接调用 PHP 内置函数或系统命令提取版本号，再做字符串比对。这意味着：
-
"php": "^8.1"等价于version_compare(PHP_VERSION, '8.1.0', '>=')，但不等价于"php": ">=8.1.0 —— 后者更精确，前者可能因 Composer 内部解析逻辑略宽松 -
"ext-intl": "~7.4"实际检查的是INTL_ICU_VERSION（ICU 版本），不是 PHP 版本；若系统 ICU 是 73.2，~7.4会被判定为不匹配（因~7.4→>=7.4.0 ） -
"ext-opcache": "dev-main"直接被忽略，Composer 不会尝试“拉取”它，也不会报错，但也不会做任何版本检查
所以别依赖 ^ 的“智能推导”，对虚拟包，显式写 >=、 更可靠。
conflict 中声明虚拟包要特别小心
你可以在 conflict 里阻止某些环境组合，但必须确保语法合法且意图清晰：
-
"conflict": {"php": "8.2.5"}→ 合法，表示禁止在 PHP 8.2.5 下安装 "conflict": {"ext-gd": " → 合法，但前提是 GD 扩展本身暴露了可读版本（如通过 <code>gd_info()返回GD Version字段）-
"conflict": {"lib-icu": "73.*"}→ 合法，会排除所有 ICU 73.x 版本 -
"conflict": {"ext-zip": "dev-develop"}→ 无效，Composer 忽略该条目，不报错也不生效
最容易被忽略的一点：conflict 中的虚拟包约束，只在 composer update 时参与 SAT 求解，composer install 完全不检查——它只照 composer.lock 还原，哪怕当前环境已违反 conflict 条件，也不会中断安装。
