应优先明确环境与项目要求不一致的根本原因，再选择临时跳过（--ignore-platform-reqs 或 --ignore-platform-req）、项目级禁用（"platform-check": false）或修复环境；切勿盲目忽略。
composer install 时提示 “Your platform config allows the installation of a package…” 怎么办
这是 Composer 在 2.2+ 版本默认开启平台检查（platform-check）后，发现你本地 PHP 或扩展版本与 composer.json 中声明的 config.platform 或依赖包要求冲突时抛出的警告（或错误，取决于配置）。它不阻止安装，但会中断交互式流程、影响 CI/CD 自动化。
根本原因不是“要绕过检查”，而是你本地环境和项目预期不一致 —— 可能是开发机 PHP 版本低、没装 ext-gd 这类扩展，或者 CI 环境故意用旧 PHP 测试兼容性。
- 临时跳过：运行
composer install --ignore-platform-reqs（全局禁用，含 PHP 版本、扩展、其他包版本） - 精准跳过：用
--ignore-platform-req指定单个项，比如composer install --ignore-platform-req php或--ignore-platform-req ext-gd - CI 场景更推荐后者，避免因忽略
php导致装了不兼容的包而 runtime 报错
如何永久禁用 platform-check 而不改全局配置
别碰 composer global config —— 那会影响所有项目。正确做法是在项目级 composer.json 里关掉它：
在 composer.json 的 config 段加一行：
{
"config": {
"platform-check": false
}
}
这个设置只对当前项目生效，且优先级高于全局配置。下次 composer install 就不会触发平台检查逻辑。
- 注意：设为
false后，composer update也不会校验平台兼容性，得自己确保 PHP 和扩展满足依赖要求 - 如果项目用了
config.platform（比如强制指定"php": "8.1"），关掉platform-check不会取消该模拟行为，只是跳过“你本地是否达标”的检查 - Git 提交前确认团队是否接受此配置 —— 它相当于把兼容性责任从工具移交到人
platform-check 和 config.platform 的关系容易搞混
config.platform 是“假装你有某个环境”，用于构建可复现的 lock 文件；platform-check 是“检查你真实有没有那个环境”。两者独立，但常被一起修改，导致误判。
-
"platform": {"php": "8.0"}→ Composer 生成 lock 时按 PHP 8.0 解析依赖，但不检查你本机是不是真有 8.0 -
"platform-check": true（默认）→ 安装时比对你本机 PHP 版本是否 ≥ lock 文件里记录的最低要求（由platform或依赖自身声明决定） - 常见错误：只配了
platform却没开platform-check，结果在低版本 PHP 上装了高版本才有的函数调用，运行时报Undefined function - 另一个坑：CI 用 Docker 拉了 PHP 8.2 镜像，但忘了装
ext-bcmath，此时platform-check会报错，而--ignore-platform-reqs会掩盖这个缺失
为什么 --ignore-platform-reqs 在某些 CI 环境下仍失败
因为部分托管 CI（如 GitHub Actions 的某些 PHP setup action）会在 composer install 前自动注入 --no-interaction --no-progress，但不会帮你加 --ignore-platform-reqs。如果你的脚本没显式带上它，还是会卡住。
- 检查 CI 日志里实际执行的命令，确认是否真的包含了
--ignore-platform-reqs - 有些 Composer 插件（如
hirak/prestissimo）或自定义脚本可能重写参数，导致你的 flag 被丢弃 - 最稳妥的做法：在 CI 脚本中明确写出完整命令，例如：
composer install --no-interaction --ignore-platform-reqs - 如果用了
composer.lock，且 lock 文件里记录的依赖已满足你当前平台，其实根本不需要 ignore —— 此时报错大概率说明 lock 文件和当前平台声明不匹配，该重新composer update（在目标平台上）
platform-check 的设计本意是防踩坑，但当开发环境、测试环境、生产环境版本策略不统一时，它就成了开关而不是护栏。关它不难，难的是关完之后，谁来验证 PHP 函数是否存在、扩展是否可用、类型声明是否被支持 —— 这些事不会因为加了个 flag 就自动做完。
