结论：composer install 报“依赖不匹配”，90% 是 composer.lock 与当前环境不兼容，不是配置写错了，也不是网络问题——删 vendor 和 composer.lock 再重装，往往比调参数快得多；因为 install 只按 lock 还原，而 lock 可能由不同 PHP 版本、扩展或镜像源生成，导致校验失败或平台不匹配。
直接说结论：composer install 报“依赖不匹配”，90% 是 composer.lock 与当前环境不兼容，不是配置写错了，也不是网络问题——删 vendor 和 composer.lock 再重装，往往比调参数快得多。
为什么删 lock 文件反而能解决问题
Composer 的 install 命令只照着 composer.lock 还原依赖，完全不看 composer.json 里的版本约束。如果这个 lock 文件是在另一台机器、另一个 PHP 版本、甚至另一个镜像源下生成的，它里面记录的包版本、校验值、扩展要求就可能和你本地对不上。
常见触发场景：
- 从 Git 拉下来的项目，
composer.lock是别人用 PHP 8.2 + ext-posix 生成的，而你本地是 PHP 8.1 + Windows（没 posix） - CI 流水线用了镜像源打包，但你本地切回了官方源，
composer.lock里记录的 dist URL 和 checksum 对不上 -
composer.json里改了 PHP 版本要求，但没运行composer update --lock，旧 lock 文件还在强行拉老包
composer install --ignore-platform-reqs 不是万能解药
这个参数确实能跳过 PHP 版本和扩展检查，但它掩盖的是底层不兼容——装得上，不一定跑得动。
比如：
- 你在 PHP 7.4 上用
--ignore-platform-reqs强装 Laravel 11，composer install成功，但php artisan直接报ParseError: syntax error, unexpected token "="（Laravel 11 用了 PHP 8.2 的属性初始化语法） - 跳过
ext-redis检查后装了predis/predis，但代码里写了new Redis()，运行时抛Class 'Redis' not found -
--ignore-platform-reqs会同时绕过所有扩展、PHP 版本、ICU、lib-* 校验，风险不可控；更安全的做法是只绕单个：如--ignore-platform-req=ext-posix
镜像源导致的 checksum mismatch 怎么快速验证
报 Package checksum mismatch for vendor/some/package，本质是镜像返回的 ZIP 包和官方不一致，不是你本地坏了。
别急着删缓存或重配镜像，先用两行命令验证：
- 清本地缓存再走官方源：
composer install --no-cache加环境变量COMPOSER_REPO_PACKAGES=https://repo.packagist.org composer install - 如果这步成功，说明就是镜像污染；失败则问题在别处
- 检查当前镜像是否生效：
composer config -g repo.packagist，输出必须是完整 JSON，且url末尾带/，type字段必须显式为"composer"
真正该优先做的三件事
遇到“依赖不匹配”，别一上来就改配置、加参数、换镜像。先做这三步，省下调试两小时：
- 确认
php -v和php -m | grep输出，和composer.json里require.php及扩展要求是否基本对得上 - 运行
composer validate，看配置文件本身有没有语法错误或非法字段 - 删掉
vendor/和composer.lock，然后composer install—— 如果项目没有硬性要求必须锁定旧版依赖，这是最干净的起点
复杂点在于：有些项目把 composer.lock 当作部署契约，删了就得重新测试兼容性；而很多人忽略的是，lock 文件一旦跨平台生成，它本身就可能已携带不可移植的假设。
