composer install在旧PHP上失败是因环境契约被打破，主因包括lock文件中包要求高PHP版本、platform配置与实际不符或扩展缺失，须回退兼容包版本或升级PHP而非绕过校验。
旧版 PHP 环境（如 PHP 7.2–7.4）仍广泛存在于遗留系统或受限容器中，但 composer install 并非“只要能跑就没事”。它会严格校验 composer.lock 中每个包声明的 php 版本约束，一旦不匹配，直接报错退出——这不是警告，是硬性拦截。
为什么 composer install 在旧 PHP 上突然失败
错误提示常为 Your requirements could not be resolved，但它不是依赖冲突，而是环境契约被打破。核心原因有三：
-
composer.lock里某包（比如monolog/monologv3.x）要求php: ">=8.1"，而你本地是 PHP 7.4 -
composer.json顶部"config": {"platform": {"php": "8.2.10"}}显式锁死了平台版本，但实际运行环境是 PHP 7.3 - 扩展缺失：
ext-json、ext-mbstring或ext-xml未启用，composer diagnose会明确标出
不加 --ignore-platform-reqs 的替代方案
加 --ignore-platform-reqs 是临时止血，不是治疗。装完大概率在运行时报 Class not found 或 Function undefined。真正可行的做法是：
- 用
composer show vendor/package-name查看目标包各版本对 PHP 的真实要求，回退到兼容旧版的最后一个 minor 版（例如symfony/consolev5.4 是 PHP 7.2+ 最后支持版本） - 本地执行
composer update vendor/package-name:^5.4，再提交更新后的composer.lock，确保所有环境按同一套低版本约束还原 - 若项目已锁定高版本包且无法降级，必须升级 PHP 环境——别试图绕过 platform 检查，那等于把 runtime 错误延迟到第一次请求时爆发
Docker 构建中旧 PHP 的陷阱
在基于 php:7.4-cli 的 Dockerfile 里，以下写法极危险：
立即学习“PHP免费学习笔记（深入）”；
FROM php:7.4-cli COPY composer.json composer.lock ./ RUN composer install --no-dev --optimize-autoloader
问题在于：如果 composer.lock 是在 PHP 8.2 下生成的，构建会静默失败或跳过关键包。安全做法是：
- CI 流水线第一步加
grep -o '"php": "[^"]*"' composer.lock | head -1，确认锁文件声明的 PHP 版本 ≤ 基础镜像版本 - 构建前用
composer check-platform-reqs（Composer 2.2+）做预检，失败则中断 - 绝不复用跨 PHP 大版本的
composer.lock—— 它不是通用快照，而是带平台签名的契约文件
旧 PHP 环境下最常被忽略的一点：即使 composer install 成功了，vendor/autoload.php 加载时仍可能因扩展缺失或函数废弃而 fatal error。务必在安装后跑一次 php -d display_errors=1 -f vendor/autoload.php 做最小验证。
