Composer 严格依据 php -v 的 CLI 版本校验 composer.json 中的 PHP 约束，不匹配则中止安装；需统一 PHP 路径、用 --ignore-platform-req=php 精准跳过校验，或通过 config.platform.php 编译期伪装版本，但不可替代真实环境兼容。
直接结论：不是 Composer 本身不兼容，而是它在用 php -v 输出的 CLI 版本，严格比对 composer.json 中 "php" 字段的约束（如 "^8.2"），不匹配就硬性中止——不生成 vendor/，也不写 composer.lock。
先确认真实 PHP CLI 版本，别被 alias 或 Web 环境骗了
Composer 只看 php -v，和 Nginx/Apache 的 PHP-FPM 版本、IDE 内置终端配置、甚至 which php 显示的路径都可能不一致。常见错误是改了 FPM 配置却忘了重启终端，导致 php -v 还是旧版本。
- 执行
php -v，记下输出（例如PHP 8.1.28） - 再跑
composer diagnose | grep "PHP binary"，对比它调用的是否和which php一致 - 如果不一致，Composer 实际用的是另一个 PHP，必须统一路径或显式指定二进制
用 --ignore-platform-req=php 精准跳过，别碰 --ignore-platform-reqs
这个参数只绕过 PHP 版本校验，其他扩展（ext-mbstring、ext-xml）、库（lib-curl）、ICU 版本仍被检查——避免装完就 Fatal error: Class 'Redis' 这类更难定位的问题。
- 命令必须带等号：
composer install --ignore-platform-req=php，漏掉=php会报错 - 如果还缺扩展（比如
ext-gd），追加第二个参数：--ignore-platform-req=ext-gd - 该参数仅影响当次命令，不写入配置，不污染
composer.json - CI/CD 中建议加
--no-interaction --prefer-dist一起用
多 PHP 版本共存时，显式调用目标二进制最可靠
别依赖 update-alternatives 或 brew unlink/php-switch 切全局默认，容易干扰其他项目或系统工具。Composer 不读 phpinfo()，也不认 Web SAPI，它只执行你 shell 里 php 命令指向的二进制。
立即学习“PHP免费学习笔记（深入）”；
- Linux/macOS：
/usr/bin/php8.2 composer install - Windows：
"C:\php\php82\php.exe" composer install - CI 脚本中务必前置
php -v打日志，确认生效版本 - 切换 PHP 后，必须删掉
vendor/和composer.lock再重装——复用旧vendor可能因反射行为差异导致autoload_static.php加载失败
config.platform.php 是“编译期伪装”，不是运行时魔法
它只在 install/update 阶段起作用，告诉 Composer：“请按这个 PHP 版本去选包”。但它不会让 PHP 7.4 支持 match 表达式，也不会让 readonly 属性在旧版本里生效。
- 适用场景：PHP 7.4 开发机上为 PHP 8.2 生产环境提前打包
vendor/ - 禁用场景：本地 PHP 是 7.4，却设
"platform": {"php": "8.2"}后直接跑 Laravel 11 —— 一运行就ParseError: syntax error, unexpected token "match" - 设置后必须跟
composer update --lock，否则composer.lock仍记录旧版本包 - 该配置不被子项目继承，每个项目需单独设置
真正容易被忽略的是：PHP 版本不匹配只是表象，背后常混着 composer.lock 锁定高版本依赖、repositories 覆盖镜像导致解析卡住、或两个包在 require 中声明了互斥的 PHP 约束——这些情况下加 --ignore-platform-req=php 完全无效，得查 composer prohibits 或跑 composer update --dry-run 定位冲突源。
