应使用--ignore-platform-req=php精准跳过PHP版本检查，而非--ignore-platform-reqs；后者会一并跳过所有扩展、库及架构校验，导致装入不兼容包而运行时崩溃。
直接加 --ignore-platform-reqs 能跳过 PHP 版本检查，但这是最粗暴的方式——它同时跳过所有扩展、系统库校验，极易导致后续运行时报错。真正安全、常用的做法是只跳过 PHP 版本本身，用 --ignore-platform-req=php。
为什么 --ignore-platform-reqs 不是首选？
这个参数名字带 s，本质是“忽略全部平台要求”，包括 ext-gd、ext-mbstring、lib-curl 甚至 php 自身。你本地缺 ext-redis，它假装有；PHP 是 8.3.0RC1，它假装满足 ^8.2。结果就是 composer install 成功了，但 php artisan serve 一跑就报 Class 'Redis' not found 或 ParseError: syntax error（比如用了 PHP 8.3 的新语法，而代码实际只兼容 8.2）。
-
--ignore-platform-reqs不解决缺失扩展，只让 Composer “闭眼装” - 它不会改
composer.lock里记录的 PHP 兼容性元信息，CI 构建时仍可能失败 - 多人协作时，别人拉代码后执行
composer install，会因环境差异突然报错，问题难复现
--ignore-platform-req=php 才是精准解法
只跳过 PHP 版本比对，其他平台依赖（如扩展是否启用）仍被严格校验。适合你当前 PHP 版本高于项目声明（例如项目写 "php": "^7.4"，你本地是 8.2），且确认代码实际兼容的情况。
- 命令写法必须带等号和值：
composer install --ignore-platform-req=php，不能写成--ignore-platform-req（后者等价于--ignore-platform-reqs） - 多个要忽略的项可重复写：
composer update --ignore-platform-req=php --ignore-platform-req=ext-gd - 该参数仅影响当次命令，不写入配置，不污染
composer.json - 若需长期生效（如 CI 脚本中固定绕过），推荐在
composer.json的config.platform下声明虚拟版本："php": "8.2.0"，而非全局配置
删 composer.lock 和版本冲突不是一回事
如果你看到的错误是 Your lock file does not contain a compatible set of packages，说明 composer.lock 和 composer.json 的语义化版本约束冲突（比如 lock 里是 monolog/monolog:2.8.0，而 json 里写了 "^3.0"）。这时 --ignore-platform-req=php 完全无效——它不管版本逻辑，只管平台环境。
立即学习“PHP免费学习笔记（深入）”；
- 唯一有效动作是删掉
composer.lock，再跑composer install，让 Composer 完全按composer.json重算依赖树 - 删锁文件后安装结果可能和原来完全不同，尤其当多个包都满足
^3.0时，选哪个由 Composer 内部策略决定 -
--force-reinstall或--no-check-publish-date都不能绕过这个检查
运行时报错还跟 platform ignore 有关？
有些命令行工具（如 vendor/bin/phpunit、larastan）启动时自己做 PHP 版本校验，和 Composer 安装阶段无关。这时候加 --ignore-platform-req=php 没用。
- 它们的
require字段里如果写了"php": "^8.1"，运行时就会拒绝启动 - 解决方案只有三个：降级工具版本（改
require-dev）、用phpunit --no-configuration等工具自有参数跳过内部检查、或换到匹配的 PHP 环境运行 - 别指望 Composer 的忽略参数能影响这些二进制的运行时行为
最常被忽略的一点：跳过 PHP 版本检查只是让安装流程走通，不代表代码真能在那个版本上稳定运行。尤其是用了 match 表达式、|| 空合并运算符、或依赖新扩展 ABI 的包，跳过检查后第一行代码就可能崩。务必在目标环境中验证实际运行效果，而不是只看 composer install 是否成功。
