应优先修复CI环境而非盲目加--ignore-platform-reqs；若必须使用，仅限composer install阶段，并配合config.platform声明目标平台，避免在update时误用导致锁文件不兼容。
CI中执行composer install报“Your platform does not meet the requirements”怎么办
直接加--ignore-platform-reqs能绕过，但不是所有场景都该用——它跳过的是PHP版本、扩展（如ext-zip）、函数（如pcntl_fork）等运行时依赖检查，而CI环境往往和线上不一致，硬跳容易掩盖真实兼容性问题。
常见错误现象：本地装得通，CI里composer install失败，提示类似Your requirements could not be resolved to an installable set of packages，但翻日志发现根本原因是php: >=8.2或ext-gd: *不满足。
- 只在CI构建阶段临时跳过：CI脚本里明确加
--ignore-platform-reqs，但确保composer.json里的config.platform已设为生产环境目标值（比如"php": "8.1.0"） - 别在
composer update时用：这会让锁文件记录不匹配实际平台的依赖，下次install可能出 runtime error - CI镜像若已预装对应PHP和扩展，优先修复环境而非跳过检查——比如GitHub Actions用
shivammathur/setup-php指定版本+扩展，比加参数更可靠
--ignore-platform-reqs和config.platform的区别在哪
--ignore-platform-reqs是运行时开关，彻底不校验当前PHP环境；config.platform是声明式模拟，告诉Composer“假装我有这些平台条件”，它仍会按这个“假环境”解析依赖并写入composer.lock。
使用场景：你想在PHP 8.3开发机上生成适配PHP 8.1服务器的锁文件，就该设"platform": {"php": "8.1.0"}，而不是每次install都加--ignore-platform-reqs。
-
config.platform写在composer.json里，对所有环境生效；CI中若覆盖它（比如用COMPOSER_PLATFORM_CHECK=0），反而可能破坏锁文件一致性 -
--ignore-platform-reqs不改变锁文件内容，只影响安装过程——如果锁文件本身是基于错误平台生成的，跳过检查也救不了运行时报错 - 两者同时存在时，
--ignore-platform-reqs优先级更高，但这是兜底手段，不是常规方案
GitHub Actions / GitLab CI里怎么安全加--ignore-platform-reqs
只在composer install步骤加，且必须配合--no-interaction --prefer-dist --optimize-autoloader等CI常用参数，避免交互卡住或下载慢拖垮流水线。
示例（GitHub Actions）：
run: composer install --no-interaction --prefer-dist --optimize-autoloader --ignore-platform-reqs
容易踩的坑：
- 没加
--no-interaction：某些旧版Composer在CI里会卡在“do you want to store credentials?”提示上 - 在
composer update步骤误加：导致composer.lock记录了不兼容的包版本，后续部署到低版本PHP直接挂 - GitLab CI缓存
vendor/但没缓存composer.lock：锁文件更新后，缓存的vendor可能和新锁文件不匹配，此时加--ignore-platform-reqs只是让错得更隐蔽
为什么有时候加了--ignore-platform-reqs还是装不上
因为错误根本不在平台检查——比如网络超时、私有包仓库认证失败、composer.json语法错误、或依赖冲突本身和PHP版本无关。
典型现象：composer install --ignore-platform-reqs仍报错，但错误信息是Could not find package xxx at any version或Failed to download xxx: The "https://..." file could not be downloaded。
- 先看完整日志，确认最后一行错误是不是平台相关——如果不是，加参数毫无意义
- 私有仓库场景下，CI里没配置
auth.json或token，--ignore-platform-reqs完全不解决认证问题 - 某些扩展（如
ext-sodium）在PHP 7.2+是核心扩展，但Windows下可能默认不启用，这时跳过检查后运行时仍会报Call to undefined function sodium_crypto_secretbox()
平台检查只是第一道门，门开了不代表屋里没陷阱。真正要盯的是错误最末尾那行具体提示，而不是一看到“platform”就条件反射加参数。
