必须在require中写"php": "^8.1"，否则config.platform.php仅模拟解析环境，不校验真实PHP版本，无法阻止不兼容包安装或运行时因新语法（如match）崩溃。
必须在 require 中写 "php": "^8.1"，否则任何 platform 配置都只是“假装”，拦不住不兼容的包被装进来。
为什么 config.platform.php 单独用不管用
它只让 Composer 在解析依赖时「假装」运行在某个 PHP 版本下，不影响项目本身对环境的承诺。比如你本地是 PHP 8.2，但 config.platform.php 设为 "8.0.30"，Composer 就会跳过要求 php: ^8.1 的包——但它不会阻止你把一个实际依赖 match 表达式的代码部署到真·PHP 8.0 环境里崩掉。
常见错误现象：composer install 成功了，上线一跑就 ParseError: syntax error, unexpected token "match"。
-
config.platform.php不校验你本地 PHP 是否真满足项目需求 - 它不触发
composer validate的环境检查 - 它对已存在的
composer.lock无强制刷新作用，除非加--update-with-dependencies或--lock
require.php 才是真正起效的约束点
这个字段是项目级契约：声明“我这段代码需要什么 PHP 能力”。Composer 安装或更新时，会拿它和你当前 php -v 的结果比对，不匹配就直接报错退出。
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
正确写法示例：
{
"require": {
"php": "^8.1",
"monolog/monolog": "^3.0"
}
}
- 用
^8.1，不是8.1.*或>=8.1.0—— 前者语义清晰且被 Packagist 正确识别 - 别写进
require-dev，那只会约束 dev 工具，不影响主依赖 - 如果项目用了 PHP 8.2+ 特性（如只读属性），就必须写
"php": "^8.2"，不能为了“兼容”降级约束
CI/CD 中怎么安全覆盖平台版本
开发机用 PHP 8.2，但 CI 要验证 PHP 8.0 兼容性？硬编码 config.platform.php 到 composer.json 会污染本地开发体验。
推荐做法是命令行临时覆盖：
- CI 启动时执行：
composer config platform.php 8.0.30 - 紧接着跑：
composer install --no-dev --no-interaction --platform=php:8.0.30 - 加
--no-plugins更稳妥，防止某些插件绕过平台模拟 - 切记：
composer install默认不重校验require.php，所以得确保 CI 环境真实运行在目标 PHP 版本容器里，而不是靠 platform 欺骗过关
锁文件里怎么看 PHP 版本是否生效
别光信 composer.json 里写了什么，打开 composer.lock 搜 "platform" 字段：
- 如果看到
"platform": {"php": "8.0.30"}，说明config.platform.php生效了 - 但更关键的是看
"packages"下每个包的require字段是否真的没拉到 PHP 8.1+ 才支持的版本 - 执行
composer show php查当前解析所用的平台 PHP 版本（显示的是platform.php值，不是php -v）
最易忽略的一点：require.php 只管安装阶段，不拦运行时。你写了 "php": "^8.3"，但服务器上跑的是 8.1，代码照样执行——直到遇到第一个 8.3 特性才挂。这个 gap 得靠 CI + 真实环境测试来补，不是靠配置能填平的。
