应确认并统一php版本：先执行php -v和which php检查实际调用的cli版本，再通过切换系统默认php（如brew link php@8.2）、指定php路径执行（如/usr/bin/php8.1 composer install）或精准跳过检查（--ignore-platform-req=php）解决，config.platform.php仅影响依赖解析，不改变运行时环境。
composer install 报 “requires php ^8.1 but your PHP version (7.4.33) does not satisfy that requirement” 怎么办
这不是 Composer 在刁难你，而是它正用当前 shell 里 php 命令的真实版本（即 php -v 输出）去校验 composer.json 中的 "php": "^8.1" 约束。不匹配就拦，没商量。
常见误操作包括：
- 只改了 Web 服务器（如 Nginx + PHP-FPM）的版本，但终端
php -v还是旧版 - 在 Windows 上改了
PATH，却没检查composer.bat第二行是否硬编码了@php或绝对路径（比如C:\php74\php.exe） - 用
update-alternatives或 Homebrew 切了系统默认 PHP，结果影响其他项目或 CI 脚本
最稳的做法：不改环境，直接喂对解释器。Linux/macOS 执行：/usr/bin/php8.1 composer install
Windows 执行："C:\php\php81\php.exe" composer install
为什么删了 vendor 和 composer.lock 还报错
因为冲突根源不在缓存，而在运行时环境没对齐。删了重装，只是用当前 php 版本再跑一遍依赖解析——如果 php -v 还是 7.4，而 composer.json 写着 "php": "^8.1"，报错必然重现。
必须确认三件事一致：
-
php -v输出的目标版本 -
which php指向的二进制路径 -
composer config platform.php（如果设了）的值
尤其注意：vendor/autoload_static.php 是按真实 PHP 版本生成的。PHP 8.2 的 match 表达式在 7.4 下根本无法解析，哪怕文件存在，一加载类就 ParseError。
config.platform.php 是“伪装”，不是“切换”
"config": { "platform": { "php": "8.2.0" } } 只影响 composer update 阶段的依赖求解，告诉 Composer：“请按 PHP 8.2 来选包”。但它不改变任何运行时行为：
-
vendor/autoload_static.php仍由你当前真实的 PHP 版本生成 -
scripts里写的"test": "php tests/run.php"还是调php命令，不受该配置影响 - 扩展是否启用（如
ext-mbstring）、函数是否存在（如str_contains()），全看真实环境
适用场景极窄：比如你在 PHP 7.4 开发机上，要为 PHP 8.2 生产环境提前打包部署包。禁用场景更关键：本地是 7.4 却设 "platform": {"php": "8.2"} 后直接跑 Laravel 11 ——readonly、命名参数这些语法，7.4 根本不认识。
CI 脚本和多项目混用时怎么避免踩坑
别靠 export PATH 或 alias composer= 长期绑定 PHP 版本，不同项目可能要求 8.1、8.2、8.3，硬绑定反而增加维护成本。
推荐写死路径，明确、可复现：
- GitHub Actions：
run: /usr/bin/php8.3 /usr/local/bin/composer install - GitLab CI：
script: /opt/homebrew/bin/php@8.2 /usr/local/bin/composer update - 宝塔用户：
/www/server/php/83/bin/php /usr/bin/composer require monolog/monolog
务必在脚本开头加 php -v 和 which php 打日志，否则出问题时连哪个 PHP 在跑都搞不清。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
