应先运行php -v和which php确认CLI真实PHP版本及路径，再比对composer.json中require.php约束；若不匹配，需显式调用目标PHP二进制执行Composer（如/usr/bin/php8.2 composer.phar install），并删除vendor和composer.lock后重装。
composer install 报“PHP version does not satisfy”怎么办
不是 Composer 拒绝工作，是它正在用你当前 shell 里的 php 命令校验约束——而这个版本很可能和项目要求不匹配。比如项目 require "php": "^8.2"，但 php -v 输出的是 7.4.33，报错就必然发生。
别急着改系统默认 PHP 或删 vendor，先确认两件事：
- 运行
php -v和which php，看输出是否一致、是否是你想用的版本（如/usr/bin/php8.2） - 如果
which php返回的是/usr/bin/php这类软链，它可能指向旧版；直接用完整路径调用更可靠 -
platform配置（如"platform": {"php": "8.2.0"}）只影响依赖解析阶段，不会让 PHP 7.4 突然支持match表达式——运行时报错说明 runtime 和 platform 不一致
如何让 Composer 固定使用某个 PHP 版本
靠 alias 或改 PATH 在 CI、Git hooks、Makefile 里大概率失效。真正稳定的方式只有两种：
- 显式调用：Linux/macOS 下用
/usr/bin/php8.2 composer.phar install；Windows 下用"C:\php\php-8.2\php.exe" composer.phar update（引号不能少） - 设
COMPOSER_PHP环境变量（Composer 2.2+ 支持）：COMPOSER_PHP=/usr/bin/php8.1 composer install - 注意：如果
which composer返回的是 shell 脚本（开头#!/usr/bin/env php），COMPOSER_PHP无效，必须退回到显式调用php8.1 /path/to/composer.phar
切换 PHP 版本后为什么还要删 vendor 和 composer.lock
因为 vendor/autoload_static.php 等文件的生成逻辑与 PHP 版本强相关：不同版本下反射行为、常量解析、语法树遍历方式可能不同，导致自动加载映射错位或缺失。
立即学习“PHP免费学习笔记（深入）”；
这不是“建议”，是硬性步骤：
- 删掉
vendor/和composer.lock - 确认
php -v已是你目标版本 - 再执行
composer install（不是update） - 若跳过这步，即使安装成功，运行时也可能出现
Class not found或ParseError
为什么不能靠 COMPOSER_VENDOR_DIR 实现多项目隔离
设置 COMPOSER_VENDOR_DIR 让多个项目写入同一目录，等于主动制造冲突。Composer 没有运行时包版本隔离能力，所有 require 都走同一个 vendor/autoload.php，而该文件只注册最后写入的那个版本的 PSR-4 映射。
后果很直接：
- 项目 A 安装
monolog/monolog:^2.9，项目 B 安装^3.0，最终vendor/monolog/monolog里只有一份代码 - B 的代码调用
Monolog\Logger::create()（v3 新增方法），实际加载的是 v2 的类，报Call to undefined method - Web 服务器配置中 root 指向错误目录、Docker 构建漏掉
composer install，也会复现同类问题
每个项目必须拥有独立的 composer.json 和 vendor/ 目录，且 Web 入口（如 public/index.php）只能 require 本项目的 vendor/autoload.php。
