composer --version 显示的是 Composer 自身版本（如 2.7.7）及官方 PHAR 构建时间戳（非安装时间），不反映 PHP 版本、项目依赖或运行环境；确认其调用的 PHP 真实路径应使用 composer diagnose 查看 “PHP binary” 行，而非仅依赖 php -v。
composer --version 显示的只是 Composer 自身版本，和你项目实际运行时调用的 php CLI 完全无关——90% 的“PHP 版本不匹配”问题，根源不在 Composer，而在 php 命令指向了错误的二进制文件。
怎么确认 composer 调用的是哪个 php
Composer 默认使用 php 命令启动，但它不关心这个 php 是谁。你终端里敲 php -v 看到的版本，和 composer install 里解析 config.platform.php 或校验扩展时用的 php，可能根本不是同一个。
- 运行
which php和command -v php，看路径是否一致；Mac 上尤其注意 Homebrew 安装的/opt/homebrew/bin/php和系统自带的/usr/bin/php混用 - 执行
composer diagnose，它末尾会打印PHP binary: /path/to/php—— 这个才是 Composer 真正用的 - 在 Docker 或 CI 中，
php可能被 alias 或 wrapper 脚本劫持，用ls -l $(which php)查真实指向 - 某些 IDE（如 PHPStorm）内置终端会加载不同 shell 配置，导致
php -v和composer diagnose输出不一致
为什么 composer check-platform-reqs 报 ext-zip 缺失，但 php -m 显示有
因为 composer check-platform-reqs 读的是它自己调用的那个 php 二进制所加载的扩展，而 php -m 走的是你当前 shell 的 php。两者 PATH 不同、配置文件（php.ini）不同、甚至 SAPI 类型（cli vs embed）都可能不同。
- 对比
php --ini和composer diagnose输出的PHP loaded configuration file是否一致 - 运行
/path/to/composer-php -m | grep zip（把/path/to/composer-php替换为composer diagnose显示的真实路径），才能确认 Composer 看得见什么 - 常见陷阱：MAMP、XAMPP、Valet 等环境会自带独立 PHP，但没加进全局 PATH，导致
composer用系统默认 PHP，而php -v用的是 MAMP 的
config.platform.php 和真实 php -v 不一致怎么办
config.platform.php 是 Composer 的“模拟层”，它会覆盖真实 PHP 版本做依赖解析。但这个覆盖只影响 require 约束判断，不影响运行时行为——也就是说，即使你设 "php": "8.1.0"，实际跑 vendor/bin/phpunit 仍用系统真实 PHP，该崩还是崩。
立即学习“PHP免费学习笔记（深入）”；
- 先删掉
config.platform.php，用真实php -v运行composer install -v，看是否还有冲突；如果没报错，说明平台配置纯属误导 - 如果必须保留 platform（比如 CI 需要统一环境），确保它和 CI 所用 PHP 版本严格一致，否则
composer.lock生成的依赖树可能在本地运行时报Class not found - 运行
composer show --platform查 Composer 当前“认为”的 PHP 版本和扩展，它反映的是 platform 配置 + 实际检测的混合结果，不是单一来源
composer install 报错 “Your requirements could not be resolved” 却没提 PHP 版本
这种报错往往藏得深。Composer 默认不会把 PHP 版本不匹配作为第一行错误抛出，而是表现为某个包“无法满足约束”，比如 monolog/monolog 2.10.0 requires php ^7.2 || ^8.0，但你的 php -v 是 8.3 —— 表面看没问题，实则 config.platform.php 锁死了 "php": "8.1.0"，导致 Composer 拒绝所有要求 ≥8.2 的包。
- 加
-v参数重跑：composer install -v，翻到最后几行，找requires php字样，确认是哪个包在卡住 - 临时注释掉
config.platform块，再跑一次composer install --dry-run -v，对比输出差异 - 用
composer depends -r php查哪些包直接或间接锁定了 PHP 版本（注意：这个命令需要 Composer 2.5+） - 别信
php -v输出的 “8.3.0RC1” —— Composer v2.7+ 对 RC 版本支持不稳定，建议降级到 8.3.0 stable 再试
真正难排查的从来不是版本号本身，而是同一台机器上同时存在多个 php、多个 composer、多个 php.ini，而你只改了一个地方，却以为全局生效。
