正确绕过“require does not match”校验的方法是删除 composer.lock 后运行 composer install，或使用 composer update --lock 仅更新 lock 文件结构而不更改依赖版本。
composer install 时提示 “require does not match” 怎么绕过版本检查
Composer 默认严格校验 composer.lock 中记录的依赖版本与 composer.json 的 require 声明是否一致。如果手动改过 require 但没更新 lock 文件，composer install 就会报错，而不是自动重算依赖。
真正能跳过这个校验的是加 --ignore-platform-reqs 吗？不是——那是忽略 PHP/扩展版本要求。这里要的是「接受当前 lock 文件，哪怕它和 json 不匹配」，正确做法是：
- 删掉
composer.lock，再跑composer install（最干净，但会重解全部依赖） - 或者用
composer update --lock：它只更新 lock 文件结构、不改依赖版本，能修复 json/lock 不一致问题 - 强行覆盖？
composer install --no-interaction不行，它不会跳过校验；--force-install不存在
想装一个 composer 包，但它的 require 写了 "php": "^8.1"，而你本地是 PHP 7.4
这不是“忽略版本限制”，而是平台需求冲突。Composer 默认拒绝安装不兼容的包，因为运行时大概率出错。
如果你明确知道该包实际兼容旧版 PHP（比如作者写严了），可以用：
-
composer require vendor/name --ignore-platform-reqs：跳过所有平台检查（PHP 版本、扩展是否存在等） - 更稳妥点：只忽略 PHP 版本，
composer require vendor/name --ignore-platform-req=php - 注意：
--ignore-platform-reqs不影响依赖解析逻辑，只放行安装；但若包内部用了 PHP 8.1 特性（如枚举），运行时直接 fatal error
composer require 强制安装某个版本，不管其他包是否冲突
Composer 的依赖解析器本质是 SAT 求解器，它不会“强制覆盖”。所谓“强制”，其实是绕过解析、直接写进 composer.json 并跳过一致性检查。
常见误操作：composer require vendor/name:1.2.3 --update-with-dependencies —— 这反而会让 Composer 更努力地找兼容解，可能升级一堆其他包。
- 真要硬上：先
composer require vendor/name:1.2.3 --no-update（只写 json，不装） - 再手动编辑
composer.json，把该包的 version 改成"1.2.3 as 2.0.0"（版本别名，欺骗解析器） - 最后
composer update vendor/name --with-all-dependencies，并准备好处理冲突提示 - 风险：可能破坏 autoloading，或导致
vendor/autoload.php加载失败——因为某些包的 PSR-4 命名空间在 1.2.3 和 2.x 差异很大
CI 环境里频繁遇到 “Your requirements could not be resolved”
不是版本写错了，而是 CI 缓存了旧的 composer.lock 或镜像源状态不一致。本地能装，CI 报错，八成是平台差异或缓存污染。
- CI 脚本开头加
composer self-update --2（确保用 Composer 2.x，v1 的解析器行为不同） - 不要用
composer install+composer update混用；CI 应该只跑composer install --no-interaction --prefer-dist - 如果 lock 文件是 PHP 8.2 下生成的，CI 用 PHP 8.0 运行
install，必须加--ignore-platform-req=php，否则直接退出 - 镜像源超时也常伪装成版本冲突：加
-vvv看真实错误，可能是Connection refused被吞掉了
最麻烦的其实是 lock 文件里混进了 dev-main 或分支别名，这种版本在 CI 的只读环境下根本拉不到——得确认 minimum-stability 和 prefer-stable 设置是否合理，而不是一上来就加 ignore 参数。
