composer 2.5+强制要求php ≥ 8.0.2，不满足则直接报错拒绝启动；需用php -v和php $(which composer) --version交叉验证版本匹配性，php 7.4等旧环境必须降级composer至2.4.x或锁定兼容旧版依赖。
Composer 不支持旧版 PHP，不是设计疏忽，而是每个稳定版本都硬性声明了最低 PHP 要求——不满足就直接拒绝启动，连解析 composer.json 都不会做。
Composer 2.5+ 彻底放弃 PHP
从 Composer 2.5.0 开始，官方移除了对 PHP 7.x 的所有支持。这不是“兼容性变差”，而是明确划界：composer --version 输出为 2.5.x 或更高时，php -v 必须 ≥ 8.0.2。低于该版本会直接报错 Unsupported version，且错误信息里通常带 requires PHP >= 8.0.2 这类提示。
- Composer 2.4.x 是最后一个支持 PHP 7.2.5–8.1 的主版本
- Composer 1.x 最高只到 PHP 7.4，且早在 2022 年已 EOL（停止维护）
- 别信
which composer显示的路径——有些环境残留着软链接指向只读的composer.phar，实际执行版本可能和预期不符
为什么不能“降级适配”而必须换 PHP？
Composer 的依赖解析逻辑深度绑定 PHP 运行时能力。比如它要判断某个包能否安装，就得知道当前环境是否支持 match、enum、只读属性等语法特性。这些特性在 PHP 解析器层面才存在，Composer 无法在 PHP 7.4 里“模拟”出 PHP 8.1 的语义检查能力。
- PHP 版本约束写在
composer.json的require.php字段里，是包作者声明的底线，不是建议 -
--ignore-platform-reqs只是跳过校验，不是补丁：装进去的代码一旦用到#[\Attribute]，运行时立刻ParseError: syntax error, unexpected Attribute - 某些包（如
symfony/consolev6）根本不提供 PHP 7 兼容分支，Composer 没得选，只能报错
怎么确认是不是 Composer 和 PHP 版本真不匹配？
别猜，用两条命令交叉验证：
- 查真实 PHP 版本：
php -v（注意：Composer 只认 CLI 版本，Web 环境无关） - 查 Composer 实际执行版本：
php $(which composer) --version（绕过 shell alias 或 wrapper） - 如果
php -v输出PHP 7.4.33，而composer --version是2.7.7，那必然崩——2.7.7 要求 PHP ≥ 8.0.2
此时重装 Composer 没用，必须先升级 PHP；若暂时无法升级 PHP，则只能锁死 Composer 在 2.4.x，并接受部分新包不可用。
旧项目还在用 PHP 7.4，现在想加个新包却失败怎么办？
核心思路不是让 Composer “支持旧 PHP”，而是让新包“适配旧 PHP”：
- 先查目标包在 Packagist 上的版本支持矩阵，比如访问
https://packagist.org/packages/monolog/monolog#v2.9.3，看右下角Requires PHP字段 - 明确指定兼容版本：
composer require monolog/monolog:^2.9（而非默认的^3.0） - 或临时用
config.platform.php声明目标环境：composer config platform.php "7.4.33"，再跑composer update --lock - 注意：
platform配置只影响依赖解析，不改变运行时行为——它不能让match()在 PHP 7.4 里跑起来
最易被忽略的一点：CI/CD 脚本里没打 php -v 日志，导致排查时反复在“是 Composer 问题”和“是 PHP 问题”之间摇摆。实际只要一行日志，就能省掉半天时间。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
