应优先用--ignore-platform-req=php精准跳过PHP版本检查，而非--ignore-platform-reqs全局跳过；后者在update中风险更高，因会重解析依赖树并可能装入不兼容版本，导致运行时崩溃。
别用 composer update --ignore-platform-reqs 代替环境对齐——它不修复兼容性，只掩盖问题。真要绕过 PHP 版本限制，优先用 --ignore-platform-req=php，而不是全局跳过。
为什么 composer update --ignore-platform-reqs 风险比 install 更高
update 会重新解析整棵依赖树、尝试升级到最新满足约束的版本，而 --ignore-platform-reqs 会让 Composer 在“假装所有平台都满足”的前提下做决策。结果可能是：装进一个只兼容 PHP 8.2 的包，但你本地是 PHP 7.4，运行时直接 Fatal error: Uncaught Error: Call to undefined function str_contains()。
-
install默认按composer.lock还原，只要 lock 文件当初能装上，通常不会触发平台冲突 -
update不读 lock 的平台快照，而是实时重算——此时跳过检查，等于把兼容性判断权完全交给 Composer 的推测逻辑 - 如果你的
composer.json里有"conflict": {"php": ">=8.3"}，--ignore-platform-reqs也拦不住，照样失败
--ignore-platform-req=php 才是精准解法
它只跳过 PHP 版本校验，保留对 ext-mbstring、ext-gd 等扩展的检查，能帮你暴露真实缺失项，而不是一并掩盖。
- 正确写法：
composer update --ignore-platform-req=php（注意等号后是php，不是版本号） - 大小写敏感：
ext-zip不能写成zip或Ext-Zip - 可叠加多个：
composer update --ignore-platform-req=php --ignore-platform-req=ext-gd - 该参数从 Composer 2.2 起支持，低于此版本会静默忽略
CI/CD 中最常踩的坑：加了 flag 却没锁 PHP 版本
GitHub Actions 或 GitLab CI 里写 composer update --ignore-platform-reqs，但 job 没指定 php-version，结果跑在默认 PHP 7.4 上——测试通过，部署到 PHP 8.1 环境后报错。
立即学习“PHP免费学习笔记（深入）”；
- 必须显式声明运行时版本，例如 GitHub Actions 中加
php-version: '8.1' - Docker 构建中，base image 的 PHP 和扩展要和
config.platform或实际需求一致，不能靠 flag “硬顶” -
--ignore-platform-reqs不改composer.lock的平台字段，但生成的 lock 可能记录了无法在目标环境运行的包版本
config.platform 是持久化伪装，不是忽略
往 composer.json 里写 "platform": {"php": "8.1.0"}，不是让 Composer 忽略检查，而是告诉它：“当前环境就是 PHP 8.1.0”，从而影响依赖解析结果——比如选一个标称支持 8.1 但内部用了 8.1.10 新特性的包。
- 它对
install和update都生效，且会污染composer.json，新成员 clone 后直接继承这个“假环境” -
"platform": {"php": null}或空字符串会报错，null不是合法值 - 它不解决
vendor/bin/phpunit启动时自身的 PHP 版本校验（那是 phpunit 自己写的逻辑）
真正麻烦的不是装不上，而是装上了却在 runtime 崩溃——尤其当项目启用了 opcache，错误可能延迟几小时才暴露。所以每次加 --ignore-platform-req，都要问一句：我确认这段代码没用那个版本的新语法，也没依赖那个扩展的特定功能吗？
