Composer虚拟包是声明环境能力的逻辑占位符（如ext-gd、php），不提供代码，仅参与依赖解析；多版本PHP环境下报错源于实际扩展与项目require不匹配，config.platform仅欺骗解析器，无法解决运行时缺失扩展问题。
什么是 Composer 虚拟包，它和多版本环境有啥关系
虚拟包（virtual package）不是真实存在的包，而是 Composer 用来“占位”或“声明能力”的逻辑概念，比如 ext-gd、php、lib-icu。它不提供代码，只参与依赖解析——当某个真实包在 require 里写了 "ext-gd": "*"，Composer 就会检查当前运行环境是否“提供”这个虚拟包。
多版本 PHP 环境下出问题，往往不是因为虚拟包本身变了，而是你本地 PHP 版本/扩展状态和项目要求不一致，导致 Composer 在 install/update 阶段就卡住，报类似 Your requirements could not be resolved 的错误。
为什么 config.platform 不能解决所有虚拟包兼容问题
"config": {"platform": {"php": "8.2.12", "ext-gd": "8.2.12"}} 是“假装有”，但它只骗过依赖解析器，不改变实际运行时能力：
- 它能让
composer install成功生成vendor/，哪怕你本地是 PHP 7.4 + 没装 gd - 但一旦运行
new \Imagick()或调用imagecreatefrompng()，照样报错：函数不存在或类未找到 -
ext-posix、ext-pcntl这类 Windows 根本不提供的扩展，platform设了也白设——运行时直接 Missing extension - 某些包（如
spatie/browsershot）会在post-install-cmd脚本里检测extension_loaded('gd')，这时platform完全无效
如何让虚拟包适配真正可运行的多环境
核心思路：把“依赖解析期”的虚拟包声明，和“运行时”的实际能力解耦。不靠欺骗，而靠收敛和兜底：
- 删掉
composer.json中对非必需扩展的硬性require，比如"ext-posix": "*"；改用运行时判断：if (function_exists('posix_getpid')) { ... } - 对必须的扩展（如
mbstring、openssl），确保所有目标环境都安装——Ubuntu 上补php8.2-mbstring，macOS Homebrew 装php@8.2时加--with-mbstring - 用
composer.lock锁死解析结果，避免不同机器上因平台差异重新求解出不同版本分支 - CI/CD 流水线中，用显式 PHP 路径运行命令：
/usr/bin/php8.2 /usr/local/bin/composer install --no-dev，保证解析和后续测试用的是同一套环境语义
容易被忽略的关键点
虚拟包不是配置项开关，它没有“启用/禁用”状态。你看到的 ext-xxx 是否满足，完全取决于：php -m 输出里有没有它，以及该扩展是否真的能加载成功（比如 ext-redis 加载失败时，php -m 可能仍显示 redis，但 extension_loaded('redis') 返回 false）。别只信 composer diagnose 的“Platform packages”列表，得跑一句 php -r "var_dump(extension_loaded('gd'));" 真实验证。
