答案是必须确保php -v、which php和composer diagnose三者指向同一PHP 8.1+版本，并在composer.json require中明确声明"php": ">=8.1.0"，同时清除缓存并重算依赖。
composer install 报 “requires php ^8.1 but your PHP version (7.4.33) does not satisfy that requirement”
这不是 Composer 故意卡你，而是它在用 php -v 输出的真实版本去比对 composer.json 里写的 "php": "^8.1"。不匹配就硬拦——它不关心你“以为”自己切到了新版本。
常见真实原因：
- 终端没重启，
php -v显示的是旧版本，但which php和composer diagnose | grep "PHP binary"指向的却是另一个路径（比如宝塔 wrapper 脚本、alias、PATH 顺序错乱） - 你改了系统默认 PHP（如用
update-alternatives），但 CI 或 IDE 的 shell 环境没同步，导致实际执行 Composer 的仍是老 PHP -
composer.json里没写死"php"约束，团队有人 push 了基于 PHP 8.2 生成的composer.lock，你在 PHP 7.4 上直接composer install就必然失败
为什么删了 vendor 和 composer.lock 还报同样错
因为问题不在文件，而在环境没对齐。删了重装只是用当前 php 命令再跑一遍解析逻辑——如果 php -v 还是 7.4，而 composer.json 要求 8.1+，错误会原样重现。
必须确认三件事同时成立：
立即学习“PHP免费学习笔记（深入）”；
-
php -v输出是你目标版本（如 8.2.0） -
which php和composer diagnose | grep "PHP binary"返回的路径一致 -
composer.json的require段明确写了"php": ">=8.1.0"（别用^8.1，语义易歧义）
config.platform.php 是不是万能解药
不是。它只在依赖解析阶段“假装”你是某个 PHP 版本，运行时不会变——本地是 PHP 7.4 却设 "platform": {"php": "8.2"}，composer install 能过，但一跑 match 或 readonly 就 Fatal error。
适用场景极窄：
- CI 打包时明确指定目标服务器 PHP 版本，且所有包已验证兼容
- 你在低版本开发机上为高版本生产环境预生成 vendor（需配合
composer update --lock）
禁用场景：
- 把它提交到共享仓库，让所有人继承
- 本地开发时设了 platform 却不验证语法是否真能跑
- 用它代替真实的 PHP 版本切换
升级 PHP 后 composer install 还失败？缺这三步
Composer 不会自动感知 PHP 版本变化，它复用 composer.lock 里旧的解析结果。哪怕你已经切到 PHP 8.2，只要 lock 文件是为 8.1 生成的，某些包的版本可能已不兼容新环境。
必须手动做：
- 运行
php -v和php -m，确认版本和关键扩展（mbstring、curl、openssl）都就位 - 执行
composer clear-cache，清除平台感知缓存 - 用
composer update --with-all-dependencies强制重算整个依赖图，而不是只跑composer install
最容易被忽略的是：不清理缓存就直接 update，Composer 可能仍沿用旧的 platform-check 结果，导致看似成功实则埋雷。
