最准解法是直接用目标PHP二进制路径执行，如/usr/bin/php8.2 composer install；因Composer仅依赖shell中php命令指向的CLI版本，与php-fpm、nginx或phpinfo()无关，三者（php -v、composer diagnose、which composer）必须一致，否则autoload等文件将因版本错配导致运行时错误。
直接用目标 PHP 二进制路径执行 composer install，比如 /usr/bin/php8.2 composer install —— 这是最准、最可控、副作用最小的解法。其他方法要么绕过检查埋雷，要么伪造环境导致运行时报错。
为什么 php -v 和 Composer 报的版本对不上
Composer 完全不看 php-fpm、nginx 或 phpinfo()，它只认当前 shell 中 php 命令的真实指向。常见错位场景：
- 你用宝塔或 XAMPP 装了多个 PHP，但
which php指向的是旧版（如/www/server/php/74/bin/php） - CI 流水线里设了
PHP_VERSION=8.2，但没改$PATH，php -v仍是 8.1 -
composer是个 shell wrapper 脚本（不是 phar），硬编码了#!/usr/bin/env php，而env php又被 alias 或 PATH 干扰
验证方式必须三者交叉比对：php -v、composer diagnose | grep "PHP version"、head -n1 $(which composer)。
--ignore-platform-req=php 能用，但别乱加 --ignore-platform-reqs
前者只跳过 "php": "^8.2" 类声明；后者会一并跳过所有 ext-*、lib-* 甚至架构检查，极易导致运行时 Class 'Redis' not found 或 syntax error, unexpected token "match"。
立即学习“PHP免费学习笔记（深入）”；
- 错误信息明确含
php ^8.2→ 加--ignore-platform-req=php即可 - 同时提示
ext-gd is missing→ 单独加--ignore-platform-req=ext-gd，别一股脑上-reqs -
--ignore-platform-reqs（带 s）在 CI/Docker 构建中慎用：builder 镜像装了它，runtime 镜像没装扩展，部署后必崩
config.platform.php 是“编译期欺骗”，不是运行时升级
它只影响依赖解析阶段（install/update），告诉 Composer “按这个 PHP 版本来选包”，但 runtime 还是当前 CLI 版本。适用场景极窄：
- 你在 PHP 7.4 机器上，要为 PHP 8.2 生产环境提前打包 vendor 目录
- CI 流水线中明确指定目标平台，且所有依赖已验证兼容
禁用场景更关键：
- 本地 PHP 是 7.4，却设
"platform": {"php": "8.2.0"}后直接跑 Laravel 11 →match、readonly等语法在 7.4 下根本不存在 - 该配置提交到团队仓库，队友没统一环境 → 有人
install成功，一运行就ParseError - 设完必须跟
composer update --lock，否则composer.lock仍记着旧版本包
切换 PHP 版本后必须删 vendor 和 composer.lock
vendor/autoload_static.php 和 autoload_classmap.php 是根据当前 PHP 版本的反射行为、语法支持（如联合类型、match）、扩展加载顺序动态生成的。PHP 8.3 下生成的 autoload 文件，在 7.4 上执行大概率直接 ParseError。
- 不要复用旧
vendor，哪怕只是换了个小版本（如 8.2.10 → 8.2.12） - 推荐做法：每个 PHP 版本对应独立子目录，用
composer config vendor-dir vendor-php82动态设置 - Docker 多阶段构建中，builder 阶段用目标 PHP +
--ignore-platform-req=php或platform，runtime 阶段必须确保真实环境装齐对应扩展
真正容易被忽略的点是：composer install 的结果不是纯文本文件，而是与 PHP 解释器深度耦合的产物；只要 php -v、composer diagnose、which php 三者不一致，后续所有操作都在沙上筑塔。
