Composer的platform配置是声明目标部署环境PHP及扩展版本的虚拟能力声明，仅影响依赖解析阶段的包版本选择，不改变实际运行环境，必须置于composer.json根级config.platform下且值为具体版本字符串。
什么是 Composer 虚拟包的 platform 配置
Composer 本身不提供“虚拟包”实体，platform 是 composer.json 中一个特殊配置节，用于**声明当前运行环境的底层能力**，让依赖解析器跳过对真实已安装扩展或 PHP 版本的探测，直接按你写的值做兼容性判断。它不是安装包，也不生成文件，只影响 composer install 时的版本选择逻辑。
platform 配置必须写在根项目 composer.json 里
它只在项目根目录的 composer.json 中生效，不能放在 vendor 包或全局配置里。常见误操作是把它加到 config 或 require-dev 下——那完全无效。
-
"platform"必须是顶层键，与"require"同级 - 值必须是对象，键名只能是
"php"、"ext-xxx"（如"ext-redis"）、"lib-xxx"（如"lib-curl"） - 值为字符串，表示“这个环境声称自己有该组件，且版本为 X.X.X”
示例：
{
"require": {
"php": "^8.1",
"ext-redis": "*"
},
"platform": {
"php": "8.1.25",
"ext-redis": "5.3.7",
"lib-curl": "7.81.0"
}
}
platform 和实际环境不一致会出什么问题
Composer 不校验 platform 声明是否真实——它信你。但 PHP 运行时会校验。典型后果：
- 声明了
"ext-redis": "5.3.7"，但实际没装 ext-redis → 运行时报Class 'Redis' not found - 声明了
"php": "8.3.0"，但实际是 8.2.12 → 某些语法（如enum析构函数）直接 Parse Error - 声明了
"lib-openssl": "3.0.0"，但系统是 1.1.1 → 扩展加载失败或 TLS 握手异常
所以 platform 不是用来“绕过检查”的，而是用来**锁定构建环境语义**：比如 CI 流水线用 Docker 构建，但目标部署机 PHP 版本略低，就靠它让 composer install 选兼容旧版的依赖组合。
platform 配置无法覆盖 require 中的约束强度
platform 只能“向下兼容”，不能“向上突破”。比如：
-
"require": {"php": ">=8.4"}+"platform": {"php": "8.3.0"}→ 安装失败，因为 8.3.0 不满足 >=8.4 -
"require": {"php": "^8.1"}+"platform": {"php": "8.3.0"}→ 正常，Composer 会据此选适配 8.3 的包版本 -
"require": {"ext-gd": "*"}+"platform": {"ext-gd": "not-installed"}→ 无效，值必须是合法版本字符串，不能是任意文本
真正容易被忽略的是：一旦设了 platform，所有子依赖的平台约束都会基于这个“虚拟环境”计算，而不是你本地 php -v 或 php -m 的真实输出。调试时别只看本地 PHP 版本，先确认 composer.json 里的 platform 是否静默覆盖了它。
