composer install 严格校验 composer.lock 与 composer.json 版本约束一致性，不匹配则报错；唯一绕过方式是删除 composer.lock 后重装，此时转为重新解析依赖树而非验证快照。
composer install 会校验 lock 文件与 composer.json 的版本约束匹配性
Composer 没有「关闭版本约束检查」的开关。composer install 默认行为就是严格比对 composer.lock 中记录的每个包版本是否仍满足 composer.json 里声明的约束。不匹配就直接报错：Your lock file does not contain a compatible set of packages。
这不是 bug，是设计使然——lock 文件本意就是固化依赖快照，而 composer.json 是人类可读的“意图描述”。两者冲突说明意图已变，必须显式决策。
--ignore-platform-reqs 不影响依赖版本校验
--ignore-platform-reqs 只跳过 PHP 版本、扩展（如 ext-zip）等平台能力检查，对 monolog/monolog: "^3.0" 这类依赖版本约束完全无效。
- 它不会让
composer.lock里存着2.8.0却允许composer.json改成"^3.0"后还能 install 成功 - 它也不会帮你绕过
require-dev里某个包导致的约束冲突 - 真正被忽略的只有
php、ext-*、lib-*这三类 platform 包
唯一绕过 lock-file 约束校验的方式是删掉 composer.lock
想让 Composer 完全按 composer.json 重新解析依赖树，而不是校验 lock 文件，唯一可靠做法就是：
- 删除当前目录下的
composer.lock - 运行
composer install（此时等价于composer update的依赖求解逻辑）
注意：这不是“跳过检查”，而是切换到另一套检查逻辑——从“验证快照一致性”变成“重新生成快照”。结果可能完全不同，尤其当多个版本都满足 ^2.0 时，新生成的 lock 文件很可能选中更新的 patch 版本，甚至不同 minor 分支。
想临时放宽某包的稳定性限制，别动全局 minimum-stability
如果报错是 Could not find a matching version，且你确认目标版本存在（比如 3.0.0-RC2），问题往往出在稳定性过滤上。
-
"minimum-stability": "stable"是默认值，会直接屏蔽所有(RC)、(dev)标签的版本 - 不要全局改成
"dev"，那会让所有未显式标注稳定性的依赖都开始拉dev-main - 正确做法是显式带稳定性后缀：
composer require vendor/package:3.0.0-RC2 --stability=RC - 或在
composer.json的 require 条目里写："vendor/package": "3.0.0-RC2 as 3.0.0"（注意as后必须是合法版本号，不能带-RC2）
真正的复杂点在于：版本约束不是孤立生效的，它和 stability、platform、lock 文件状态、甚至 Packagist 的同步延迟都耦合在一起。调试时别只盯着 composer.json 改来改去，先用 composer show -a vendor/package 看真实可用版本，再用 composer prohibits 定位谁在阻止安装——这才是最省时间的路径。
