应使用 --platform=php:x.x.x 精准伪造php版本，而非 --ignore-platform-reqs；config.platform.php 对根包php约束无效；临时构建可用 --no-platform-check，但需确保代码语法兼容实际php版本。
composer install 时提示 “Your PHP version does not satisfy the requirement” 怎么绕过？
这是最常见现象：项目 composer.json 声明了 "php": "^8.1"，但你本地或服务器只有 PHP 7.4，composer install 直接失败。别急着升级 PHP——Composer 提供了更轻量的干预方式。
- 不要用
--ignore-platform-reqs全局跳过（它会忽略扩展、PHP 版本、所有包约束，极可能装出无法运行的依赖） - 正确做法是用
--platform精准伪造平台环境，例如：composer install --platform=php:7.4.33
- 这条命令告诉 Composer：“就当我的 PHP 是 7.4.33”，它会据此筛选兼容的依赖版本，而不是硬卡在
^8.1上 - 注意：该参数只影响本次命令，不修改
composer.lock或全局配置；下次不加仍会校验真实环境
为什么 config.platform.php 不生效？
很多人在 composer.json 里写了：
"config": { "platform": { "php": "7.4.33" } } 却发现 composer install 还是报错。原因很实在：
-
config.platform只在当前项目中生效，且仅对 require 的包起作用，对 root package（即本项目自身）的php约束无效 - 换句话说：你写
"php": "^8.1"在require里，config.platform能压住；但如果你把它写在 root 的require同级（即声明本项目所需 PHP 版本），它就完全不参与校验逻辑 - 解决方案只有两个：要么删掉 root 的
php约束（如果只是开发用），要么坚持用命令行--platform覆盖
伪造 PHP 版本后，会不会装到不兼容的扩展或函数？
会，但风险可控——关键看你怎么用。
-
--platform=php:7.4.33只影响 Composer 对依赖版本的解析，不会阻止安装含match表达式、str_contains()等 8.0+ 函数的代码 - 所以它适合两类场景：
- 你明确知道所选依赖的低版本分支（比如
monolog/monolog:^2.0在 PHP 7.4 下完全可用） - 你只是临时构建、打包、生成 autoload 文件，不立即执行业务逻辑
- 你明确知道所选依赖的低版本分支（比如
- 如果真要运行，务必确认：
- 所有已安装包的
composer.json中require.php字段 ≤ 你的实际 PHP 版本 - 没有包在
autoload.files或autoload.ps4里偷偷加载了高版本语法的文件
- 所有已安装包的
替代 --platform 的更安全做法：用 platform-check 关闭校验
如果你只是想让 CI 或 Docker 构建不因 PHP 版本中断，又不想伪造版本号，可以关掉平台检查本身：
立即学习“PHP免费学习笔记（深入）”；
composer install --no-platform-check
- 它跳过所有平台约束（PHP 版本、扩展、64 位等），但不跳过依赖版本冲突检测，比
--ignore-platform-reqs安全得多 - 缺点：无法指定“我想要 PHP 7.4 的兼容集”，它只是静默通过；所以更适合已知依赖干净、仅需生成 autoloader 的场景
- 配合
COMPOSER_NO_INTERACTION=1使用更稳定，避免交互式提示干扰自动化流程
实际项目里，最常踩的坑不是参数写错，而是以为伪造了 PHP 版本就万事大吉——结果运行时报 ParseError: syntax error, unexpected token "string"。那说明某个包的自动加载文件用了 8.0 的标量类型声明，而你没意识到它根本没被 platform 过滤掉。
