composer.json 中的 php 字段是告诉 composer 项目依赖代码所支持的 php 版本范围，composer 在 install/update 时校验当前 php 版本是否满足约束，不满足则报错；它仅影响依赖解析，不影响运行时。
composer.json 里写 php 是给谁看的？
它不是让 Composer 自己切 PHP 版本，而是告诉 Composer：“这个项目依赖的代码，只保证能在指定版本及以上的 PHP 上跑”。composer install 或 composer update 时，Composer 会检查当前运行的 PHP 版本是否满足 php 约束，不满足就报错，比如：Your requirements could not be resolved to an installable set of packages. 或更直白的 PHP version x.x.x does not satisfy requirement php ^8.1。
常见错误现象：本地 PHP 8.0，但 composer.json 写了 "php": "^8.1"，执行 composer install 直接失败；或者 CI 环境用 PHP 7.4，却没改约束，导致构建卡住。
-
php字段只影响依赖解析阶段，不影响实际运行时 —— 运行项目还得靠你手动切换 PHP - 值必须是语义化版本约束（如
^7.4、>=8.0.0 ），不能写成 <code>8.1这种固定版本（那会拒绝所有补丁更新） - 如果项目真要兼容多个大版本（比如同时支持 PHP 7.4 和 8.1），得用交集写法：
">=7.4.0 ，而不是 <code>^7.4 || ^8.1（Composer 不认逻辑或）
想让 Composer 在特定 PHP 版本下运行，别靠配置，靠环境
Composer 本身没有“启动时自动切 PHP”的能力。它只是个 PHP 脚本，运行在哪版 PHP 上，就用哪版 —— 所以控制权在你手里，不在 composer.json 里。
使用场景：CI/CD 流水线要测试多 PHP 版本、本地开发需并存多个 PHP、Docker 构建时锁定版本。
立即学习“PHP免费学习笔记（深入）”；
- Linux/macOS 下，直接调用对应 PHP 二进制：
/usr/bin/php8.1 /path/to/composer.phar install - Windows 下用完整路径：
"C:\php\php-8.2\php.exe" composer.phar update - 用
phpversion()验证当前 Composer 使用的 PHP：php -r "echo phpversion();"，再套到 Composer 命令前 - 别依赖
php命令软链 —— 它容易被系统或工具（如 brew、XAMPP）悄悄改掉，CI 中务必用绝对路径
PHP 版本不匹配时，Composer 报错信息怎么看？
关键不是记错误原文，而是抓两个字段：php 和你的当前版本。错误里真正有用的线索往往藏在括号里或最后一行。
典型错误信息片段：
Problem 1
- Root composer.json requires php ^8.1 but your php version (7.4.33) does not satisfy that requirement.这里 php ^8.1 是项目要求，php version (7.4.33) 是当前环境真实版本 —— 对不上就只能换环境或改约束。
- 如果错误里出现
ext-xxx（比如ext-gd），那是扩展缺失，和 PHP 版本无关，别误判 -
composer diagnose会输出当前 PHP 版本、已加载扩展、memory_limit等，比盲猜靠谱 - 某些旧版 Composer（composer self-update
用 Docker 或 CI 时，PHP 版本最容易漏掉的一环
很多人写了正确的 php 约束、也指定了容器镜像（如 php:8.1-cli），但忘了 Composer 自身可能被缓存 —— 尤其是 GitHub Actions 的 composer/cache 或自建 CI 的 vendor 缓存目录。
后果：上一次用 PHP 7.4 装的 vendor，这次用 PHP 8.1 直接复用，结果运行时报 ParseError 或 Deprecated —— 因为某些包的 autoloader 或生成代码（如 Doctrine Proxy）跟 PHP 版本强相关。
- Docker 中每次构建建议加
rm -rf vendor composer.lock再composer install，别盲目复用 - GitHub Actions 里，不要只缓存
vendor/，而应按 PHP 版本分 cache key：composer-${{ hashFiles('**/composer.lock') }}-${{ matrix.php-version }} - 本地开发如果用
phpbrew或asdf切 PHP，记得每次切换后运行composer install，而不是沿用旧vendor
最常被忽略的其实是 vendor 目录的“版本绑定性”——它不是纯静态资源，而是跟构建时的 PHP 解析器行为深度耦合。哪怕 composer.json 写得再准，只要 vendor 是错版本下装的，运行时照样翻车。
