composer.json 中的 php 字段是最低版本要求，安装时仅比对本地 PHP 版本，不匹配则报错退出；必须写在 require 下，推荐用 ^ 或 ~ 语法，如 "^8.1"，且不自动检查扩展。
composer.json 里的 php 是最低版本要求，不是运行时检测
Composer 不会在安装时动态检查你本地 PHP 版本是否满足 require.php 的值；它只在 composer install 或 composer update 时比对当前环境的 PHP 版本和 composer.json 中声明的 php 字段。不匹配就直接报错退出，不会继续解析依赖。
常见错误现象：Your requirements could not be resolved to an installable set of packages. —— 实际可能是 PHP 版本太低，但 Composer 报错不直说，容易误以为是包冲突。
-
php必须写在require下，和其他包一样，例如："php": "^8.1" - 不能写成
"php": ">=8.1.0"这种松散格式，Composer 解析器对php的版本约束有特殊处理，推荐统一用 caret（^）或 tilde（~）语法 - 如果项目同时 require 了某个扩展（如
ext-mbstring），也要单独列在require里，php字段不自动包含扩展检查
为什么 require.php 写成 ^7.4 却在 PHP 8.0 下装不上？
因为 ^7.4 等价于 >=7.4.0 ，它明确排除了所有 8.x 版本。这是语义化版本规则决定的，不是 Composer 的 bug。
使用场景：当你维护一个只兼容 PHP 7.4 的遗留项目，又不想让它被意外装到 8.x 环境中跑崩，就得用这种“上限锁定”写法。
立即学习“PHP免费学习笔记（深入）”；
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 想兼容 7.4 到 8.2？写成
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"—— 虽啰嗦但明确 - 更简洁的等效写法：
"php": ">=7.4.0 ，注意这里用的是范围语法，不是 caret - 别信某些文档说
^7.4“默认允许小版本升级”，PHP 主版本升级不是小版本，^7.4永远不会跨主版本
platform 配置能绕过 PHP 版本检查吗？
可以，但它是“假装”有某个版本，不是真的降级或升级 PHP。常用于 CI 测试或本地开发环境不一致时。
性能 / 兼容性影响：它只影响 Composer 自身的依赖解析，不影响实际运行时行为。如果代码用了 PHP 8.1 的 enum，而你用 platform 假装是 8.1，但在 PHP 8.0 环境下执行，照样 fatal error。
- 在
composer.json顶层加："config": { "platform": { "php": "8.1.0" } } - 仅对当前项目生效，不传递给依赖包；子包仍按自己声明的
php要求校验 - CI 中慎用：它掩盖了真实环境不匹配的问题，可能导致上线后才暴露
PHP 版本要求最终由谁决定？
不是 composer.json 单方面说了算。三个地方共同起作用：
- 你的
composer.json中require.php声明 - 你依赖的每个包自己的
composer.json里的require.php - 你本地
php -v输出的实际版本
Composer 会取所有包声明的 PHP 版本交集，再和本地版本比对。所以哪怕你自己写的是 ^8.0，只要其中一个依赖要求 ^8.2，而你本地是 8.1，照样失败。最容易被忽略的是：你没动过 composer.json，但更新了一个次级依赖，它悄悄提高了 PHP 要求，导致整个项目突然装不上。
