composer.lock锁定了实际安装版本，排查重点是识别谁在使用、谁在阻拦、谁被连带影响；需检查platform段与当前PHP环境是否匹配，用composer why-not定位阻塞包，避免盲目修改lock文件。
composer.lock 里锁死的扩展版本不兼容，本质是它把“当时能跑通”的快照固化了，但环境或依赖变了——排查重点不在改 lock 文件，而在搞清谁在用、谁在拦、谁被连带拖垮。
看 composer.lock 里实际装了什么版本
别只信 composer.json 里写的约束，composer.lock 才是真实安装记录。打开它，搜索你要查的扩展名（比如 ext-redis），看 platform 或 platform-check 段是否声明了该扩展，以及它的版本是否和当前 PHP 环境匹配。
更直接的方式是运行：
composer show --platform | grep redis
如果返回空，说明 Composer 认为这个扩展没装；如果返回 ext-redis: 5.3.7 但你本地 php -m | grep redis 显示的是 ext-redis 6.0.2，那冲突就在这里——不是 Composer 错，是环境错位。
查哪个包在要求不兼容的 platform 条件
执行 composer why-not php:8.3（把 8.3 换成你目标 PHP 版本）会立刻告诉你：是 laravel/framework 要求 ^8.1，还是某个 dev 包（比如 phpunit/phpunit）硬性声明 "platform": {"php": "8.0.0"} 并写进了自己的 composer.json。
常见坑点：
-
require-dev里的包经常悄悄锁死 platform，比如老版phpunit/phpunit依赖sebastian/environment，后者又要求php >=7.3，但没声明conflict，导致 Composer 在解析时误判整个树不兼容 - 某些包在
composer.json里用"platform": {"ext-redis": ">=5.0"}，但你本地是ext-redis 6.0——这本身合法，但如果它同时写了"conflict": {"ext-redis": ">=6.0"}，那才是真冲突
验证 lock 文件是否被跨版本 Composer 污染
如果你在 CI 里用 Composer 2.5 生成了 composer.lock，但本地开发机装的是 Composer 1.10，运行 composer install 就可能报 Your lock file does not contain a compatible set of packages。
这时不是版本不兼容，而是 lock 文件格式不一致。检查 composer.lock 开头是否有 "lock-version": 2 字段（v2 格式），而你的 Composer v1 不认这个字段。
解决方法：
- 统一用项目文档指定的 Composer 版本重生成 lock：
docker run --rm -v $(pwd):/app -w /app composer:2.2 update --lock - 或者删掉
vendor/和composer.lock，再用本地 Composer 版本执行composer update --lock（注意不是install）
绕过 platform 检查要分场景，不能一棍子打死
--ignore-platform-reqs 是临时止痛药，不是诊断工具。它跳过所有平台校验，包括 PHP 版本、扩展、甚至 lib-* 库，容易掩盖真正问题。
更稳妥的做法：
- 只忽略某一项：
composer install --ignore-platform-reqs=ext-redis（适用于开发环境确实不启用 Redis 的情况） - 在
composer.json中精准控制："config": {"platform": {"php": "8.2.10", "ext-redis": "5.3.7"}}，让 Composer 按你声明的“假环境”去算依赖，而不是读取真实 PHP 状态 - 如果只是 CI 报错而本地正常，优先检查 CI 镜像的 PHP 版本和扩展是否与
composer.lock中platform段一致
最常被忽略的一点：lock 文件里的 platform 是生成时的快照，它不会随你升级 PHP 自动更新。哪怕你把 PHP 升到 8.3，lock 文件仍按 8.2 算依赖——除非你主动触发 composer update --lock。
