必须在require中声明"php": "^8.1"，否则composer按本地php-v解析依赖导致团队环境撕裂；config.platform.php仅辅助模拟环境，不能替代require.php的硬性校验。
团队成员 php -v 输出不一致，composer install 在有人机器上成功、有人失败——这不是偶然，是 composer.json 缺少明确的 PHP 引擎约束导致的必然结果。必须在 require 段声明 "php"，否则 Composer 默认按“当前环境能装啥就装啥”，根本不管团队统一性。
为什么没写 "php": "^8.1" 就会出问题
Composer 不会主动帮你锁定运行环境。如果你的 composer.json 里 require 段没声明 "php"，它就完全依赖每个开发者本地的 php -v 去解析依赖树：
- 张三本地是 PHP 8.2 → 装了
symfony/consolev6 →composer.lock记录的是 v6 - 李四本地是 PHP 7.4 →
composer install读锁文件时发现 v6 要求 PHP 8.0+ → 直接报错：Your PHP version (7.4.33) does not satisfy that requirement - 更糟的是：没人改
composer.json，但composer.lock已被 PHP 8.2 环境生成并提交 → 团队环境就此撕裂
必须在 require 里写死 php 版本号
不是靠文档约定，不是靠口头提醒，而是把最低兼容版本硬编码进 composer.json 的 require 字段：
"require": {
"php": "^8.1",
"monolog/monolog": "^3.0"
}
这样做的效果：
-
composer install会在所有机器上校验本地 PHP 是否满足^8.1，不满足立刻中断，不让你走到 autoload 或运行阶段 -
composer update只会选那些同时满足^8.1和包自身约束的版本，不会因为某人本地是 8.2 就偷偷拉高版本破坏兼容性 -
composer show --platform输出的php值会和require.php一致（除非你额外配了config.platform.php）
config.platform.php 是辅助，不是替代
它只应在极少数场景下使用，且必须配合 require.php 一起管理：
- 当你需要为低版本生产环境生成 vendor（比如开发用 PHP 8.2，部署到 PHP 7.4），才设
config.platform.php为"7.4.33"，且必须同步确保require.php也允许 7.4 - 如果
require.php是"^8.1"，却把config.platform.php设成"7.4.33"，Composer 会按 7.4 解析依赖，但锁文件仍记录着^8.1的语义，后续 CI 或他人 install 时极易混乱 - 该配置不应提交到共享仓库，除非整个团队强制统一目标平台（如全部跑 PHP 8.1 容器）
CI/CD 流水线必须验证 PHP 版本
光靠 composer install 不够，得让构建日志暴露真实执行环境：
- CI 脚本开头加：
php -v && php -r "echo 'extensions: ' . implode(',', get_loaded_extensions()) . "\n";" - 检查是否加载了项目必需的扩展（如
ext-gd,ext-mbstring），这些也会被require或platform约束 - 禁止使用
--ignore-platform-reqs进入生产流水线；它只适合本地快速验证，且必须配合--dry-run和人工核对
真正难的不是写对一行 "php": "^8.1"，而是所有人执行 php -v 时看到的版本号必须落在这个范围里——这要求团队在 PHP 版本管理上达成基础设施级共识，而不是靠 Composer 配置打补丁。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
