答案：Composer不自动检测平台变化，需手动清除缓存并执行composer update --with-all-dependencies重算依赖兼容性。PHP升级后Composer仍缓存旧解析结果，不会自动校验php平台约束，必须强制重解析依赖图。
Composer 自动检测平台要求不匹配，本质不是“检测失败”，而是它太老实——只认当前运行的 PHP 版本和已加载扩展，不会猜、不会退、也不会提醒你该切环境。 你看到 Your requirements could not be resolved 或 platform requirements mismatch，90% 是 CLI 环境和 Web 环境错位，或本地 PHP 版本根本没对上 composer.json 里写的 php 字段。
composer install 报 platform mismatch，先查真实 PHP 版本
别信 php -v 就万事大吉。很多共享主机（尤其是 cPanel）里，CLI 和 Web SAPI 是两套独立 PHP 实例：
- 用
php -v查的是命令行版本 - Web 请求实际跑在 Apache/PHP-FPM 上，版本可能完全不同
- 必须建一个
info.php文件（内容为<?php phpinfo(); ?>），通过浏览器访问，确认PHP Version和Server API字段 - 如果 info.php 显示 PHP 7.4，但 composer.json 要求
"php": "^8.1"，那报错就是必然的——Composer 没错，是你环境没对齐
为什么 --ignore-platform-reqs 不是万能解药
加了 --ignore-platform-reqs 能让安装过掉，但风险藏在运行时：
- 它跳过的是 安装阶段 的校验，不改变任何运行时行为
- 比如你用 PHP 7.4 强装 Laravel 11（要求 PHP 8.2+），
vendor/autoload.php能生成，但一执行php artisan就报syntax error, unexpected token "match" - 某些包的 bin 文件（如
vendor/bin/phpunit）自己会做 PHP 版本检查，--ignore-platform-reqs对它完全无效 - 只建议临时用于缺失非核心扩展（如
--ignore-platform-reqs=ext-gd,ext-redis），且确认项目运行时不依赖这些功能
用 platform 配置“骗过”依赖解析，但别骗自己
"config": {"platform": {"php": "8.1.0"}} 是编译期欺骗，只影响 composer update 时选哪个包版本：
- 它能让 Composer 在 PHP 7.4 环境下生成适配 PHP 8.1 的
vendor/目录（适合部署准备） - 但它不会让
str_contains()在 PHP 7.4 里突然可用——运行时仍按实际 PHP 版本执行 - 如果你本地开发环境是 PHP 7.4，又想直接跑需要 PHP 8.2 的代码，platform 配置解决不了问题，该升级 PHP 就得升级
- 拼写必须严格：值是字符串，如
"8.1.0"，不能写成8.1（缺少引号会被 JSON 解析失败）
CI/CD 或多版本共存时，靠路径，不靠软链
不要依赖系统级 php 命令软链接，它容易被 brew、XAMPP 或 host 自动覆盖：
- Linux/macOS：用绝对路径调用，例如
/usr/bin/php8.1 composer install - Windows：用完整路径，例如
"C:\php\php-8.2\php.exe" composer.phar update - 在 GitHub Actions 或 GitLab CI 中，明确指定 PHP 版本 Action（如
shivammathur/setup-php@v2），并传入php-version: 8.2 - 验证方式：在 CI 脚本开头加一行
php -r "echo phpversion();"，确保输出和预期一致
真正难处理的不是报错本身，而是错误信息里混着多个层级的约束：PHP 主版本、扩展存在性、包内嵌的 require、甚至子依赖的 conflict 字段。一旦出问题，优先看 composer why-not 和 info.php，而不是急着加忽略参数。
