应明确指定目标PHP版本执行composer install，如Linux/macOS用/usr/bin/php8.1 composer install，Windows用"C:\php\php81\php.exe" composer install，并确保php -v、which php和composer 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" 约束。不匹配就硬拦，不装、不更新、不妥协。
常见误操作包括：
- 用
update-alternatives或 Homebrew 切系统默认 PHP，结果影响其他项目或 CI 脚本 - 看到报错就加
--ignore-platform-reqs，结果 vendor 里塞进一堆 PHP 8.1 语法（比如match表达式），一运行就ParseError: syntax error, unexpected token "match" - 改了
composer.json里的platform配置却没跑composer update --lock，导致composer.lock还记着旧版本包
正确做法是让 Composer「明确知道」你要按哪个 PHP 版本解析依赖：
- Linux/macOS：直接调用目标二进制，例如
/usr/bin/php8.1 composer install - Windows：用完整路径，例如
"C:phpphp81php.exe" composer install - CI 脚本中务必前置
php -v打日志，确认生效版本
config.platform.php 是什么，什么时候该用、什么时候不该用
config.platform.php 是 Composer 唯一允许你“声明目标平台 PHP 版本”的配置项，它只影响依赖解析阶段（install/update），不改变运行时行为。
立即学习“PHP免费学习笔记（深入）”；
适用场景很窄：
- 你在 PHP 7.4 的开发机上，但要为 PHP 8.2 的生产服务器提前生成兼容的
vendor/目录（比如部署包打包） - CI 流水线中明确指定目标环境 PHP 版本，且所有包都已验证过兼容性
禁用场景更关键：
- 本地 PHP 是 7.4，却设
"platform": {"php": "8.2"}后直接跑 Laravel 11 ——match、readonly、命名参数等语法在 7.4 里根本不存在 - 把该配置提交到团队仓库，而队友环境不统一，导致有人
composer install成功但运行时报错
设置方式（仅限当前项目）：composer config platform.php "8.2.0"，之后必须跟 composer update --lock 重写锁文件。
为什么删 vendor 和 composer.lock 后问题还在
因为冲突根源往往不在缓存，而在环境不一致或约束未对齐。删了再装，只是用当前 php 版本重跑一遍解析逻辑——如果 php -v 还是错的，或者 composer.json 里仍写着 "php": "^8.1"，那报错会原样重现。
更隐蔽的问题来自 composer.lock 本身：
- 它记录的是上次成功解析时的 PHP 版本和包组合，如果之前是在 PHP 8.1 下生成的，现在用 PHP 7.4
composer install，Composer 会发现锁文件里的包（比如monolog/monologv3.x）根本不支持 7.4，于是拒绝加载并报错 - 即使你删了
vendor/和composer.lock，只要没改php命令指向或没调config.platform.php，新生成的锁文件依然会选不兼容的包
所以真正要动的不是文件，是执行上下文：确认 which php、php -v、composer config platform.php 三者是否协同一致。
composer why-not 和 composer show --tree 怎么快速定位封杀源
当报错末尾出现 Conclusion: don't install laravel/framework v11.0.0，别急着降级 Laravel。先搞清是谁在联合封杀它。
两步实操：
- 运行
composer why-not laravel/framework:11.0.0—— 它会列出所有阻断该版本的依赖链，比如package-x v2.3.0 requires laravel/framework ^10.0，这才是真凶 - 再跑
composer show --tree | grep laravel/framework，确认这个框架是不是被require-dev里的测试工具（比如orchestra/testbench）悄悄拉进来，而它又硬绑了 Laravel 10
注意：composer prohibits 查“谁不让装”，composer depends 查“谁在用它”，两者配合才能看清全貌。盲目 composer update 全量重算，可能把原本稳定的子依赖也带崩。
最常被忽略的一点：PHP 版本冲突和包版本冲突经常嵌套发生。比如你以为是 guzzlehttp/guzzle 版本不对，实际是它某个子依赖要求 PHP 8.2，而你的 php -v 是 8.1 —— 此时调 composer why-not 会直接带你看到底层那个 PHP 约束来源。
