Composer报错“Your requirements could not be resolved”主因是PHP版本不匹配，需通过composer diagnose确认实际调用的PHP路径与版本，并使用对应PHP可执行文件运行命令，而非修改composer.json中的php约束。
composer install 报错 “Your requirements could not be resolved” 且提示 PHP 版本不匹配
这是最典型的症状：运行 composer install 或 composer update 时，报错里明确出现 php: >=8.1、php: ^7.4 等版本约束，而你本地 php -v 显示的是 8.0 或 7.3 —— 不是 Composer 本身坏了，是它在忠实地执行 composer.json 里写的 require.php 规则。
常见错误现象：
• 报错末尾带一堆无法满足的依赖，但根源只有一行：Root composer.json requires php ^8.1 but your php version (7.4.33) does not satisfy that requirement.
• 用 composer --version 能跑，但装包就挂；说明 Composer 运行时调用的 PHP 解释器和你终端敲 php -v 的不是同一个（比如系统 PATH 和 CLI 默认 PHP 不一致）。
- 先确认当前 Composer 实际调用的 PHP：运行
composer diagnose，看输出里PHP binary指向哪 - 不要改
composer.json里的require.php去“降级适配”——这等于绕过项目真实运行环境要求，上线必崩 - 真正该做的是让 Composer 在正确的 PHP 版本下运行：用
php81 /path/to/composer.phar install（把php81换成你已安装的、符合要求的 PHP 可执行文件名） - macOS / Linux 下可临时设置别名：
alias composer='php81 /usr/local/bin/composer'；Windows 用户直接改系统 PATH 或用完整路径调用
修改 composer.json 的 require.php 后仍报错
改了 require.php 字段后还是报错？大概率是锁文件（composer.lock）在“固执己见”。Composer 默认优先按 lock 文件还原依赖，而 lock 文件里记录的是上次成功安装时的 PHP 版本和包版本组合。
- 删掉
composer.lock再跑composer install—— 但仅限于你完全信任当前composer.json的修改，且不介意所有依赖重新解析 - 更安全的做法是运行
composer update --with-all-dependencies，它会按新require.php重新计算整个依赖树 - 注意：如果项目用了
platform配置（如"config": { "platform": { "php": "7.4.33" } }），这个配置会覆盖你系统真实的 PHP 版本，也必须同步调整
用 Docker 或多版本 PHP 环境时，composer 找不到对应扩展
比如你在 PHP 8.2 容器里跑 composer install，却提示 ext-mbstring missing —— 这不是 Composer 的错，是 PHP 编译时没启用对应扩展，或者容器镜像精简过度。
立即学习“PHP免费学习笔记（深入）”；
- 进容器执行
php -m | grep mbstring，确认扩展是否真的加载；没输出就说明缺失 - 不要在
composer.json里加"ext-mbstring": "*"来“假装存在”，这只会掩盖问题，运行时报 Fatal Error - Dockerfile 中需显式安装扩展：Debian 系用
docker-php-ext-install mbstring，Alpine 用apk add php82-mbstring（注意 PHP 主版本号要对得上） - 某些扩展（如
ext-redis）还需额外pecl install redis并写入php.ini，漏一步都不行
全局 composer 使用了错误的 PHP SAPI（cli vs cgi）
极少数情况下，composer --version 能跑，但 composer install 却报奇怪的扩展缺失或函数不存在 —— 很可能是你系统里同时装了 CLI 和 CGI 版本的 PHP，而 Composer 调用的是 CGI 版（比如通过 Apache mod_php 注册的），它默认不加载 CLI 专用扩展（如 readline）。
- 运行
php -v和php -r "echo PHP_SAPI;"，确认当前 CLI 使用的是cli模式 - 检查
which php输出路径，再对比composer diagnose里显示的PHP binary是否一致 - 若不一致，用绝对路径强制指定：
/usr/bin/php8.1 /usr/local/bin/composer install - Mac 上通过 Homebrew 安装多版本 PHP 时，记得运行
brew link --force php@8.1确保符号链接正确
真正麻烦的从来不是改哪行配置，而是搞清 Composer 到底在用哪个 PHP、哪个 php.ini、哪个扩展目录——这些路径一旦错位，报错信息就全是误导。多看 composer diagnose，少猜。
