--ignore-platform-reqs 会跳过PHP版本、扩展存在性及platform配置检查，仅按composer.lock安装包，但不解决依赖冲突、网络问题或运行时兼容性。
为什么 composer install --ignore-platform-reqs 会“救急”
当本地 PHP 版本、扩展（如 ext-mbstring）或扩展版本不满足 composer.json 中 require 或 platform 配置时，composer install 会直接失败并报错，例如：Your requirements could not be resolved to an installable set of packages. 或更具体的 The requested PHP extension ext-gd is missing from your system.。
加 --ignore-platform-reqs 就是跳过所有平台约束检查——不看 PHP 版本、不查扩展是否启用、不比扩展版本号，只按 composer.lock 里记录的包版本硬装。
--ignore-platform-reqs 的实际影响范围
它只跳过三类检查：
• PHP 主版本和次版本（如 "php": "^8.1"）
• 扩展存在性与版本（如 "ext-curl": "^7.0"）
• platform 配置项中声明的模拟环境（常见于 CI 配置）
但它不会：
• 跳过包依赖冲突（比如两个包要求不同版本的 monolog/monolog）
• 绕过网络问题或仓库不可达
• 让已编译的扩展在运行时“自动生效”——如果缺 ext-pdo_mysql，装完照样连不上数据库
哪些场景下可以临时用，哪些绝对不能碰
可临时用：
• 本地开发机 PHP 是 8.3，但项目锁死在 Laravel 9（只支持到 PHP 8.1），你只想快速跑起来看页面逻辑
• CI 环境里 PHP 版本略高，但所有扩展都已启用，只是 Composer 担心“未来兼容性”而拦着
• 修复一个紧急 bug，需要在旧服务器（PHP 7.4）上拉取新 composer.lock，而你确认所有扩展都已手动启用
不能碰：
• 缺 ext-opcache 还强装 Laravel，后续请求会反复编译视图，性能崩盘
• php: ^8.2 的包用了 match 表达式，却在 PHP 8.0 下强装——运行时报语法错误，不是安装阶段能发现的
• 生产部署脚本里写死这个参数，等于放弃环境一致性保障
比强装更稳的替代方案
真正解决问题，优先考虑这些：
• 用 php -v 和 php -m 确认缺失扩展，然后通过包管理器安装（如 Ubuntu 上 sudo apt install php-mbstring）
• 在 composer.json 的 config.platform 里显式声明目标环境，例如：
"config": {
"platform": {
"php": "8.1.27"
}
}• 用
composer update --with-all-dependencies 替代 install，让 Composer 重新解析兼容路径（前提是 lock 文件没锁定死）• 检查是否误用了
require-dev 里的高版本工具（如 phpunit/phpunit），它们不该进生产环境
强装就像绕过红灯开车——路口没车时能省一秒，但一旦撞上 runtime 不兼容，debug 成本远高于调环境。
