--ignore-platform-reqs 仅跳过PHP版本、扩展等平台要求检查，不影响依赖版本约束；真正绕过版本校验需删除 composer.lock 后重新 install。
composer install 为什么不能用 --ignore-platform-reqs 跳过版本兼容性检查
--ignore-platform-reqs 只跳过平台要求（如 php 版本、ext-gd 是否存在），完全不碰依赖版本约束。它对 composer.json 中的 "monolog/monolog": "^2.0" 或锁文件里已记录的版本范围毫无影响。想绕过版本校验，加这个参数等于对牛弹琴。
真正能绕过依赖版本检查的唯一方式：删掉 composer.lock
Composer 默认强制校验 composer.lock 中记录的版本是否仍满足 composer.json 的约束。只要 lock 文件存在，它就不会重新解析依赖树。
- 执行
rm composer.lock（或del composer.lockon Windows） - 再运行
composer install—— 此时 Composer 会彻底忽略 lock 文件，按composer.json重新计算整个依赖图 - 注意：这会导致所有包版本重算，可能引入不兼容变更，别在生产环境直接操作
遇到版本冲突时，优先查清谁在阻止安装
与其强行绕过，不如定位具体冲突点。比如安装 foo/bar:1.2.3 失败，先运行：
composer prohibits foo/bar:1.2.3
输出会明确告诉你哪个已装包（比如 laravel/framework）和它的约束（如 "^10.0"）在阻止该版本被接受。
- 根据输出调整
composer.json中对应包的版本声明 - 或改用
composer require foo/bar:1.2.3 --update-with-dependencies让 Composer 尝试协调依赖 - 避免用
composer update --dry-run，它只预览，不解决冲突
CI/CD 中最常踩的坑：混淆 platform 和 version 两层检查
很多 CI 脚本写成 composer install --ignore-platform-reqs，结果发现 PHP 版本不一致导致某些包根本无法下载（比如 Laravel 11 要求 PHP 8.2+，但 CI 用的是 8.1 镜像），或者 ext-zip 缺失让 intervention/image 安装失败 —— 这些其实是 platform 问题；而真正卡住安装的，往往是 symfony/console 和 laravel/framework 之间语义化版本冲突，--ignore-platform-reqs 对它完全无效。
复杂点在于：你得先分清报错信息里出现的是 platform requirements mismatch（平台问题），还是 could not resolve packages（版本冲突）。前者看 PHP/扩展，后者看依赖树逻辑。混在一起处理，只会让问题更难定位。
