Composer不管理PHP版本，只依赖shell中php命令指向的解释器；报错“PHP版本不满足要求”本质是php -v显示版本低于composer.json声明要求，需通过which php确认路径并用brew link、update-alternatives或完整路径（如/php8.2 /composer install）指定正确PHP版本。
Composer 本身不管理 PHP 版本，它只认当前 shell 环境下 php 命令指向的解释器 —— 所以“路径问题”的本质，是你没控制住这个 php 命令到底是谁。
为什么 composer install 总报 PHP 版本不满足要求
常见错误现象：This package requires php ^8.1 but your PHP version (7.4.33) does not satisfy that requirement。这不是 Composer 在“挑版本”，而是它老老实实执行了 php -v，发现当前 php 命令输出的是 7.4，但 composer.json 写着要 8.1+。
- 别急着改
composer.json或加"platform": {"php": "8.1"}—— 这个配置只影响依赖选包逻辑，不改变实际运行的 PHP 解释器 - 先验证真实环境：
which php和php -v必须一致，且必须是你项目真正需要的那个版本 - Mac 用户注意 Homebrew 的
php@8.1安装后默认不会替换php命令，得手动brew link php@8.1或用完整路径 - Windows 下检查
composer.bat文件第二行是否硬编码了旧版php.exe路径
如何稳定指定 PHP 解释器路径（Linux/macOS/宝塔）
最可靠的方式永远是显式调用目标 PHP 二进制文件 + composer.phar（或全局 composer 命令），绕过 PATH 查找。
- 确认 PHP 路径存在：
/www/server/php/82/bin/php -v（宝塔）、/usr/bin/php8.1 -v（Ubuntu）、/opt/homebrew/bin/php@8.1 -v（Mac M1） - 直接执行：
/www/server/php/82/bin/php /usr/bin/composer install—— 注意：不是php composer install - 别依赖全局
composer命令的 shebang 行，它可能仍调用系统默认php；推荐统一用phpX.Y /path/to/composer.phar格式 - CI/CD 中务必写死路径，例如 GitHub Actions 的
run: /usr/bin/php8.2 composer.phar install
config.platform.php 到底该不该用
它有用，但只在特定场景下起效：你**需要生成一份适配高版本 PHP 的 vendor/ 目录，但本地开发机只能跑低版本 PHP**（比如为部署服务器预构建）。
立即学习“PHP免费学习笔记（深入）”；
- 它不会让
match()、enum或readonly在 PHP 7.4 里突然能运行 —— 运行时语法错误照报不误 - 它也不解决扩展缺失问题：
"platform": {"php": "8.2", "ext-curl": "1"}不会自动启用 curl 扩展，只是告诉 Composer “假装已启用” - 如果你本地 PHP 是 7.4，又想直接
php artisan serve起 Laravel 11，加 platform 没用；必须换真实 PHP 8.2+ 解释器 - 该配置不会被子项目继承，每个项目需单独设置，且不改变
composer global的行为
真正容易被忽略的一点：每次切换 PHP 版本后，vendor/ 和 composer.lock 必须一起删掉重装。因为 autoload_static.php 里的类映射、函数反射结果，甚至扩展检测逻辑，都可能因 PHP 版本差异而失效 —— 复用旧 vendor 是多数“明明版本对了却报错”的根源。
