config.platform.php 由 Composer 在依赖解析时读取并用于模拟 PHP 版本约束，不执行代码，仅影响版本决策；其生效取决于命令、参数、lock 文件状态及是否绕过平台检查。
composer.json 里 config.platform.php 是怎么被读取的
Composer 不会“运行”你写的 platform.php 值，它只是在解析依赖时，用这个字符串去模拟目标 PHP 版本的约束能力。也就是说，"config": {"platform": {"php": "8.2.10"}} 的作用是：让 Composer 在计算哪些包版本可安装时，假装当前 PHP 是 8.2.10，哪怕你本地实际是 8.0.30 或 8.3.5。
为什么 php -v 和 platform.php 不一致会导致 install 失败
报 Your requirements could not be resolved 时，90% 的根因不是网络或镜像，而是平台版本错配。常见现象：
- 运行
php -v输出PHP 8.0.30，但composer.json里写了"php": "8.2.10"→ Composer 会跳过所有要求^8.2的包，哪怕它们其实兼容 8.0 - 项目 lock 文件里记录了基于
8.2.10解出的依赖树，你换到 8.0 环境执行composer install，它不会重新解，但运行时可能因函数缺失直接崩溃 -
platform配置只影响依赖解析，不影响composer diagnose检查真实扩展 —— 所以 openssl 缺失报错和 platform 无关
验证 platform.php 是否真正参与了解析过程
不能只看文件里有没有那行，得看它是否被实际用于决策。最直接的验证方式是观察 composer update 行为：
- 删掉
composer.lock，确保从头解析 - 执行
composer update --dry-run -v，注意输出中类似Resolving dependencies through SAT后面是否出现platform package "php" version "8.2.10" - 对比改前改后：把
"php": "8.2.10"改成"php": "8.0.30"，再跑一次--dry-run，看可选包版本范围是否明显变窄（比如某个包从 3.5.0 降到 3.2.0） - 检查最终生成的
composer.lock顶部platform字段是否与你配置一致：grep -A5 '"platform"' composer.lock
容易被忽略的覆盖点：platform 可能被命令行参数强制覆盖
composer install 和 update 都支持 --ignore-platform-req=php 或 --ignore-platform-reqs，一旦用了这些参数，config.platform.php 就完全不生效。排查时务必确认：
- 没在 CI 脚本、Makefile 或 alias 里默认加了
--ignore-platform-reqs - 没在
COMPOSER_OPTIONS环境变量里预设了忽略项 -
composer diagnose输出末尾若带Platform requirements are ignored提示，说明当前上下文已绕过 platform 配置
真正的难点在于：platform 配置没有独立的“生效开关”，它是否起作用，完全取决于你此刻执行的是什么命令、带了什么参数、有没有 lock 文件、以及是否处于干净的解析路径上。任何一步跳过 SAT 过程（比如有 lock 文件且没加 --update-with-dependencies），它就只是个静态字段。
