--ignore-platform-reqs 是跳过平台兼容性校验的最快开关，但不解决根本问题，仅绕过检查；需配合 --config-platform 等更安全方式对齐环境。
直接说结论：依赖无法解析时，--ignore-platform-reqs 是最快能继续往下走的开关，但它不修问题，只跳过校验——装完跑不起来，得自己兜底。
为什么 composer install 卡在 “Your requirements could not be resolved”？
这不是网络或权限问题，而是 Composer 在做平台兼容性预检：它发现你本地 PHP 版本、扩展（如 ext-gd）、甚至 config.platform 声明，和 composer.lock 里记录的包要求对不上。典型触发点包括：
- 本地 PHP 是 8.3，但
composer.lock锁的是 Laravel 9（只认到 PHP 8.1） -
composer.json里写了"platform": {"php": "8.1.10"}，而你机器是 8.2.5 - CI 构建机没装
ext-igbinary，但某个包声明了"ext-igbinary": "*"
报错信息里如果出现 Your platform does not meet the minimum requirements，基本就锁定是这一类。
composer install --ignore-platform-reqs 怎么用才不翻车？
这个参数不是“万能解药”，它是把校验门禁拆了让你硬闯——闯进去之后，门后有没有坑，得你自己踩。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 只用于
install，别用在update上：否则会把不兼容的包版本写进composer.lock，污染整个团队的锁文件 - 搭配
--no-interaction和--prefer-dist：避免交互中断，也防止因源码包编译失败二次卡住 - 优先用更细粒度的
--ignore-platform-req=php或--ignore-platform-req=ext-gd：只绕过真正挡路的项，保留其他检查 - CI 脚本里加该参数时，必须同步确认部署环境真实满足要求——不能靠“先装上再说”蒙混过关
比强装更稳的替代方案：用 --config-platform 欺骗检测
它不跳过检查，而是让 Composer “以为”自己运行在目标环境上，既保住了 composer.lock 的一致性，又不用改项目配置。
- 命令行临时覆盖：
composer install --config-platform.php=8.1.27 --config-platform.ext-gd=1 - 效果等同于项目
composer.json里写了"platform": {"php": "8.1.27", "ext-gd": "*"}，但不会写入文件 - 适合多环境构建：比如开发机 PHP 8.2，但目标服务器是 8.1，你就用
--config-platform.php=8.1.0对齐 - 注意：这个参数只影响本次运行，
composer.json和composer.lock都不动
容易被忽略的关键点
很多人加了 --ignore-platform-reqs 就以为万事大吉，其实最危险的阶段在安装之后：
- 缺
ext-opcache强装 Laravel，视图渲染会反复编译，TPS 直接腰斩 - 跳过
ext-pdo_mysql检查，composer install成功，但第一次php artisan migrate就报Class 'PDO' not found -
composer create-project也吃这套参数，但模板包自身的require约束照样生效，别以为加了就一定能拉下来
真正要解决依赖解析失败，第一步永远是 composer show --platform 和 php -v && php -m 对齐环境现状，而不是急着加参数绕过。
