必须在require中写"php": "^8.1"，否则composer install不校验php版本；若存在composer.lock则跳过校验，需删锁文件或运行composer update --lock才生效；config.platform.php仅模拟依赖解析环境，不保障运行时兼容。
必须在 require 中写 "php": "^8.1"，否则 Composer 安装时根本不会校验 PHP 版本，上线后因 match、readonly 等语法直接崩掉。
为什么改了 require.php 但 composer install 不报错？
最常被忽略的事实：只要 composer.lock 存在，Composer 就默认跳过 require.php 的版本校验，直接按锁文件还原依赖——哪怕你本地 PHP 是 7.4，它也照装不误。
- 删掉
composer.lock后再跑composer install，才能触发真实校验 - 或者强制重解：用
composer update --lock，它会读取新require.php并重新生成 lock 文件 - CI 脚本里别只跑
composer install，加一步php -v验证当前 CLI 版本是否匹配声明范围
config.platform.php 不是“版本锁”，而是“依赖解析伪装开关”
它只影响 composer update 时选哪个包版本，不影响运行时行为。写成 "config": {"platform": {"php": "8.0.30"}}，只是让 Composer 假装自己在 8.0.30 下工作，但它不会阻止你把含 match 表达式的代码部署到真·8.0 环境里报 ParseError。
-
platform.php的值必须是具体字符串，如"8.0.30"或"8.1"；"^8.0"、">=8.0"这类写法会被直接忽略 - 它不校验你本地 PHP 是否真满足项目需求，也不会触发
composer validate的环境检查 - 和
require.php共存时，若二者冲突（比如require写"php": "^8.2"，platform设"8.0.30"），Composer 会直接报错：Your platform version '8.0.30' does not satisfy the required version '^8.2'
怎么安全混用 require.php 和 platform.php？
真正可行的组合只有两种，其他都是自欺欺人：
- 降低
require.php下限（比如从"^8.2"改为"^8.1"），再用platform.php模拟更低版本做兼容测试 - 仅在 CI 配置中用
platform.php固定构建环境（例如 GitHub Actions 里先composer config platform.php 8.1.22），开发时靠require.php守住底线 - CI 中必须搭配真实 PHP 版本运行测试：不能只靠
platform.php模拟，还要用php-version: '8.1'或FROM php:8.1-cli确保 runtime 一致
命令行临时覆盖比硬编码更可靠
本地开发用 PHP 8.3，但要验证能否跑在生产 8.1 环境？别在 composer.json 里硬写 platform——污染 Git、干扰队友、CI 里还得手动恢复。
- CI 启动时执行：
composer config platform.php 8.1.22，该命令只写入当前目录的composer.json，不影响 Git - 更干净的做法是用
--platform参数：composer install --platform=php:8.1.22 --platform=ext-mbstring:8.1.22，优先级最高，install/update 都生效 - 避免
--ignore-platform-reqs：它会彻底关掉所有平台检查，包括扩展，极易导致运行时出错；真要用，至少限定为--ignore-platform-req=php
最易被忽略的一点：PHP 主版本升级（如 7→8）带来的不只是语法变化，还有扩展行为变更（json_decode 返回类型、mbstring 默认编码）、废弃函数（create_function）、以及 vendor/autoload.php 自身在高版本下因旧依赖引发的 Fatal error。光靠 require.php 和 platform.php 拦不住这些，最终得靠目标环境下的完整集成测试。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
