<p>应通过 composer config platform.php 和 platform.ext-* 明确声明目标环境版本与扩展，删掉 vendor 和 composer.lock 后重装；禁用 --ignore-platform-reqs 以避免运行时错误。</p>
composer install 报错 “Your requirements could not be resolved” 且提示 platform requirements mismatch
这是最常见场景：本地 PHP 版本或扩展（如 ext-gd、ext-mbstring）低于 composer.json 中 config.platform 或依赖包的 require 声明。Composer 默认严格校验运行环境是否满足目标平台要求，不匹配就直接中断。
解决思路不是“绕过检查”，而是明确告诉 Composer：“我清楚环境不达标，但我要按目标平台规则安装（比如为线上 PHP 8.1 环境构建，而本地是 PHP 7.4）”。关键在 config.platform 配置。
- 在项目根目录运行：
composer config platform.php 8.1.0（把8.1.0换成你目标 PHP 版本） - 如果还要模拟缺失扩展，加一行：
composer config platform.ext-gd 1（值写1表示“存在”，写0会报错，所以别写0） - 执行
composer install前，确认composer.lock是基于新 platform 生成的；如果已有 lock 文件，先删掉再install，否则旧约束仍生效
用 --ignore-platform-reqs 强制装，但结果不可靠
这个 flag 确实能跳过所有平台检查，命令是 composer install --ignore-platform-reqs。但它不设置目标平台，只是“闭眼装”——可能装出无法在目标环境运行的版本（比如装了只兼容 PHP 8.2 的包，却部署到 PHP 8.0 服务器）。
它适合临时调试或 CI 中快速验证逻辑，但绝不该进日常开发流程或上线构建步骤。
- 它不会修改
composer.lock中的 platform 字段，下次不用 flag 就又失败 - 如果依赖里有
ext-redis，而你本地没装，--ignore-platform-reqs会让安装通过，但运行时Class 'Redis' not found - CI 脚本里用它，等于把环境兼容性问题拖到运行时暴露，排查成本更高
为什么 vendor/autoload.php 加载失败，和 platform 设置有关？
这不是直接因果关系，但容易被忽略：当 config.platform 设得过高（比如设成 8.3.0），而你实际用的 Composer 版本较老（如 2.2.x），它可能无法正确解析新版 PHP 的特性声明，导致生成的 autoloader 缺少某些类映射，最终 require 'vendor/autoload.php' 后调用类时报 Class not found。
- 检查 Composer 版本：
composer --version，建议 ≥ 2.5.0（对 PHP 8.3+ 支持更稳） - 升级命令：
composer self-update - 删掉
vendor和composer.lock，重跑composer install，确保 autoloader 重建
生产环境部署时，platform 配置必须和服务器一致
很多人本地设好 platform.php，测试也通过，一上生产就报错。根本原因是：生产服务器的 PHP 实际版本 / 已启用扩展，和 config.platform 声明的不一致。
比如 config.platform.php 是 8.1.0，但生产服务器是 8.1.25（没问题），可如果漏配了 platform.ext-opcache，而生产环境没开 opcache，某些包可能因反射行为异常。
- 上线前，务必在生产环境执行：
php -v和php -m，对照composer.json的config.platform字段逐项核对 -
config.platform只应声明“目标环境有啥”，不能声明“我希望它有啥” - CI 构建镜像里 PHP 版本要和生产严格一致，否则
platform失去意义
platform 配置不是开关，是契约——你承诺构建产物只运行在那个环境里。设错一个点，后面所有环节都可能无声崩坏。
