这不是 phpEnv 本身的问题，而是 CLI 下 PHP 版本低于框架最低要求；必须确保 php -v 输出 ≥ composer.json 中 "php" 约束值，通过 phpenv local 激活对应版本并验证 which php 和 hash -r 后重试。
直接结论：这不是 phpEnv 本身的问题，而是你当前 CLI 下的 PHP 版本低于框架要求的最低版本。必须让 php -v 输出的版本 ≥ 框架 composer.json 中声明的 "php" 约束值。
确认 phpEnv 当前实际调用的 PHP 版本
phpEnv 是多版本 PHP 环境管理工具，但它不自动切换系统默认 php 命令 —— 你得手动激活。常见错误是以为“装了 PHP 8.2”就等于“php 命令就是 8.2”，其实没生效。
- 运行
php -v，看第一行输出（不是配置文件路径那行） - 运行
phpenv version，确认当前激活版本（如显示8.2.12） - 若两者不一致，说明 shell 缓存或 PATH 未刷新：执行
hash -r（Linux/macOS）或重启终端（Windows） - 检查
which php是否指向~/.phpenv/shims/php；如果不是，说明 phpEnv 未正确初始化，需确认~/.phpenv/bin/phpenv init的输出已写入 shell 配置（如~/.zshrc）并重载
安装 Laravel / Symfony 等框架时指定兼容 PHP 版本
框架最新版往往只支持 PHP 8.1+，但你的 phpEnv 当前只能切到 7.4 或 8.0。别硬拉最新版，得「往回选」。
- 查清目标框架各版本的 PHP 要求：访问 Packagist 页面，例如 Laravel 9.52.16 右侧明确标着
Requires PHP: ^8.0 - 安装时显式指定版本：
composer create-project laravel/laravel myapp "9.*"（而非不带约束的默认命令） - 若已执行过失败命令，先删掉
myapp目录再重试；否则 Composer 可能残留部分不兼容文件 - 对已有项目，改
composer.json的"require": { "php": ">=8.0" }后，必须运行composer update --with-all-dependencies，仅install不会降级已锁在composer.lock中的包
临时绕过校验的几种方式及风险边界
仅限本地快速验证是否纯版本问题，绝不可用于 CI 或生产环境。
立即学习“PHP免费学习笔记（深入）”；
-
composer install --ignore-platform-req=php：跳过所有 PHP 版本检查，但一旦代码里用了enum、match或联合类型，运行时必报Fatal error -
phpenv local 8.1.0+composer install：比全局切换更安全，只影响当前目录，适合多项目混用不同 PHP 版本 -
composer config platform.php "8.0.30"：写入项目composer.json的config.platform.php字段，强制 Composer 认为平台是该版本 —— 注意：这不会让低版本 PHP 解析高版本语法，且该配置不应提交到团队仓库
为什么改完 phpEnv 还是报错？重点检查这三处
很多人激活了新版 PHP，却仍被报错，问题常出在这些隐蔽环节：
- Web 服务器（Apache/Nginx）用的是另一个 PHP SAPI：宝塔、PHPStudy、MAMP 等面板自带的 PHP 与 phpEnv 无关，需单独切换站点 PHP 版本
-
composer命令本身被 alias 或 wrapper 脚本劫持：运行type composer看是否指向/usr/local/bin/composer，而非某个封装脚本 - CI/CD 流水线（如 GitHub Actions）用的是独立 Docker 镜像，phpEnv 在本地生效，对远程构建完全无效 —— 必须在
.yml文件中显式指定 PHP 镜像，如php:8.2-cli
