答案是需手动清除缓存并重装依赖：执行composer clear-cache，删除vendor/和composer.lock，再运行composer install，以强制Composer基于当前PHP版本重新解析全部依赖。
升级PHP后直接跑 composer install 报错，不是 Composer 有 bug，而是它压根没重新校验平台兼容性——旧 composer.lock 仍按老 PHP 版本解析，新环境一执行就崩。
为什么 composer install 不自动适配新 PHP 版本
Composer 不把 PHP 版本写进 composer.lock，也不监听系统环境变化。它只认 lock 文件里“当时算出来的版本”，哪怕你刚把 PHP 从 8.1 升到 8.2，install 仍会照搬旧依赖，而某些包在 8.2 下已移除扩展（如 ext-mcrypt）、废弃函数（如 create_function），或因语法变更（如 match 表达式）直接 parse 失败。
常见错误现象：
Your requirements could not be resolved to an installable set of packages.-
Call to undefined function mb_str_split()（实际是mbstring扩展未启用，但错误被掩盖） - 报错里出现
ext-gd * -> it is missing from your system，而你确认已装——其实是 PHP CLI 和 Web SAPI 用的不是同一个php.ini
必须执行的三步清理与重装
别跳过任何一步，顺序错了会白忙活：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -v和php -m | grep -E 'mbstring|curl|json|openssl|gd'，确认 CLI 模式下扩展齐全；Web 环境另查phpinfo() - 执行
composer clear-cache，清掉平台感知缓存（否则它可能沿用 PHP 8.1 的解析结果） - 删掉
vendor/目录和composer.lock，再跑composer install—— 这是唯一能保证全量重算依赖的方式
注意：composer update --with-all-dependencies 能部分替代，但它仍依赖旧 lock 文件结构，对跨大版本（如 7.4 → 8.2）兼容性风险更高。
如何避免每次升级都手动删 lock 文件
生产项目不能总删 composer.lock，但又得确保依赖匹配当前 PHP。关键在控制解析源头：
- 在
composer.json的config段加"platform": {"php": "8.2.10"}，让 Composer “假装”当前环境就是这个版本（仅影响 install/update 阶段） - CI/CD 中固定 PHP 版本：用
phpenv或actions/setup-php@v4显式指定php-version: '8.2'，再跑composer install - 本地开发用
asdf或phpenv切换 PHP 后，立刻验证：which php和composer diagnose | grep "PHP binary"输出路径必须一致
不推荐用 --ignore-platform-reqs 临时绕过——它会装上 PHP 8.2 下根本无法运行的包，等你上线才爆 ParseError，排查成本翻倍。
composer install 报错后怎么快速定位是 PHP 版本问题
别一上来就重装 Composer 或改配置。先做最小验证：
- 运行
composer show --platform，看输出里php行的版本是否和php -v一致 - 检查
composer.lock开头的platform字段（如果有），它可能硬编码了旧版本，比如"php": "8.1.17" - 执行
composer why-not php:8.2，它会列出所有阻止升级到 8.2 的依赖链，常暴露某个子包还卡在"php": "^7.4 || ^8.0"
最隐蔽的坑是：你改了系统 PATH，但终端没 reload shell，which php 看着对，composer install 却调用的是 /usr/bin/php —— 这种路径错位，只能靠 composer diagnose 暴露。
