应仅在确认运行时环境实际满足依赖时使用--ignore-platform-reqs，它不修复问题，仅跳过校验；优先选用--ignore-platform-req=php等精准参数，避免全局跳过导致运行时崩溃。
只在确认运行时环境实际满足依赖的前提下，才用 --ignore-platform-reqs —— 它不修复任何问题，只是让安装流程跳过校验，装完就炸的风险极高。
报错 Your platform does not meet the minimum requirements 时别急着加 --ignore-platform-reqs
这个错误不是“安装失败”，而是 Composer 在提醒你：本地真实环境（php -v、php -m、ldconfig -p）和 composer.json 里声明的 config.platform 或依赖包自身的 require（如 "php": "^8.2"、"ext-gd": "*"）不匹配。
- 常见触发点包括：CI 构建机 PHP 版本比
composer.lock记录的低；本地没装ext-mbstring，但某个包硬 require 它；composer.json里写了"platform": {"php": "8.3.0"}，而你本地是 8.2 -
--no-scripts和--no-dev完全不影响这个检查，加了也没用 - 先查清到底是 PHP 版本问题、扩展缺失，还是
config.platform写得过高 —— 找到根因比绕过更省事
--ignore-platform-reqs 和 --ignore-platform-req=xxx 的区别必须分清
--ignore-platform-reqs 是全局开关，它会跳过所有平台项：PHP 版本、所有扩展（ext-gd、ext-redis）、系统库（lib-curl）一概不查；而 --ignore-platform-req=php 只跳过 PHP 版本校验，保留对扩展的检查。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer install --ignore-platform-req=php：适合本地 PHP 版本略低但扩展齐全 -
composer install --ignore-platform-req=ext-gd：适合缺图处理扩展但 PHP 版本没问题 -
composer install --ignore-platform-req=php --ignore-platform-req=ext-igbinary：可叠加多个，比--ignore-platform-reqs更可控 -
composer create-project同样受平台检查限制，必须显式加参数，比如：composer create-project laravel/laravel myapp --ignore-platform-reqs
CI/CD 中怎么用才不至于上线后报 Class 'Redis' not found
CI 脚本里盲目加 --ignore-platform-reqs，等于把兼容性问题拖到运行时暴露，排查成本更高。推荐组合策略：
- 构建镜像中已确认安装了全部扩展（如 Dockerfile 里明确
apt-get install php-redis），再用--ignore-platform-reqs - 若只为了适配目标 PHP 版本（如线上是 8.1，CI 用 8.0 构建），优先用
--platform=php:8.1.0 --platform=ext-gd:1，它会影响依赖解析，选包更准 - 避免在 CI 脚本里写死
--ignore-platform-reqs而不验证运行时环境 —— 它不会改composer.lock，下次不用 flag 就又失败 - 如果用了
config.platform，关掉platform-check不等于取消模拟行为，只是跳过“你本地有没有”的检查
永久关闭检查？别碰 global，只改当前项目 composer.json
执行 composer global config platform-check false 会污染所有项目，连新拉的 Laravel demo 都悄悄跳过检查，极不推荐。
- 安全做法是在当前项目
composer.json的config段加：{ "config": { "platform-check": false } } - 这个设置只对当前项目生效，且优先级高于全局配置
- 设为
false后，composer update也不再校验平台，得自己确保 PHP 和扩展真能满足依赖 - Git 提交前确认团队是否接受此配置 —— 它相当于把兼容性兜底责任从工具移交到人
真正容易被忽略的是：跳过平台检查 ≠ 解决运行时兼容性。装完能 require 'vendor/autoload.php'，不代表 new Redis() 就不会报 Class 'Redis' not found —— 这类错误往往要等服务启动才暴露，而那时已经晚了。
