应在 require 中写 "php": ">=8.1.0"，Composer 依据此约束决定依赖兼容性，而非检测本地 PHP 版本；本地版本不匹配时 composer install 仍执行，但运行时可能出错。
composer.json 里怎么写 PHP 版本约束
Composer 不会自动检测你当前 PHP 版本是否匹配项目需求，它只按 composer.json 里写的约束来决定能否安装依赖。关键在 "platform" 和 "config" 两处配置，但多数人其实只需要改 "require" 下的 php 字段。
常见错误是写成 "php": "^8.1" 却在 PHP 7.4 环境下跑 composer install —— 此时 Composer 会照常安装（因为本地 PHP 版本不影响解析 require），但运行时可能报错。真正起作用的是 composer update 或 CI 环境中启用 --ignore-platform-reqs 以外的场景。
"require": { "php": ">=8.1.0 是最稳妥写法，明确上下界，避免意外升级到不兼容小版本- 别用
~8.1：它等价于>=8.1.0 ，容易漏掉 8.2.x 的安全更新 - 如果项目必须适配多个大版本（如同时支持 8.1 和 8.2），写成
"php": "^8.1 || ^8.2"，但要注意依赖包是否真做了多版本兼容
为什么 vendor/autoload.php 还是报 PHP 版本错误
即使 composer.json 写对了，运行时仍提示 ParseError: syntax error, unexpected token "string" 或类似错误，大概率是某个已安装的依赖包本身用了高版本语法（比如 PHP 8.0 的联合类型），而你的 PHP 环境低于该语法支持版本。
Composer 只管“能不能装”，不管“装完能不能跑”。它不会回退到旧版包来迁就你的 PHP，除非你显式指定版本约束或启用平台配置。
立即学习“PHP免费学习笔记（深入）”；
- 检查出问题的类文件路径，用
composer show vendor/package-name查看实际安装版本 - 在
composer.json中给该包加精确版本约束，例如"monolog/monolog": "2.9.0"（这个版本支持 PHP 7.2+） - 临时验证可用
composer install --ignore-platform-reqs，但仅限调试，切勿提交到 CI 或生产环境
CI/CD 中如何强制校验 PHP 版本
本地开发机和 CI 环境 PHP 版本不一致，是最常见的线上运行失败原因。不能只靠 composer.json 约束，得让构建流程自己卡住。
GitHub Actions、GitLab CI 都支持指定 PHP 运行时，但更可靠的方式是让 Composer 在安装前主动报错。
- 在
composer.json的"config"段加上"platform": { "php": "8.1.10" }，这会让 Composer 把这个版本当作“当前环境”，从而影响依赖解析结果 - 配合
composer install --no-dev --prefer-dist使用，确保 dev-only 包不干扰主逻辑的版本判断 - CI 脚本里加一行
php -v | head -n1和预期版本比对，失败直接 exit 1，比等 Composer 报错更早发现问题
PHP 主版本升级时 composer.lock 容易忽略的点
从 PHP 8.1 升到 8.2，很多人只改了 composer.json 就跑 composer update，结果发现某些包没更新、有些新特性用不了——根本原因是 composer.lock 锁死了旧版本，而 Composer 默认不会为 PHP 版本变化自动触发重解析。
锁文件不是摆设，它记录的是“当时在什么 PHP 版本下选出来的包版本”。换 PHP 大版本后，必须让它重新评估。
- 删掉
composer.lock再composer install最彻底，但会连带更新所有包，风险高 - 推荐做法：
composer update --with-all-dependencies，它会基于新 PHP 约束重新计算整个依赖树 - 注意
composer outdated显示的“可升级”包，不一定真适配新 PHP，得看包自己的composer.json是否声明了对应phprequire
PHP 版本兼容性不是写个约束就完事的事，它横跨配置、安装、运行、构建四个环节，任一环松动都可能让问题漏到线上。最常被跳过的其实是 CI 环境里的 PHP 版本声明和锁文件刷新动作。
