Composer 的 --ignore-platform-req 仅跳过安装时扩展检查，不解决运行时因扩展缺失导致的 Class not found 等错误；正确用法需严格匹配 require 中的平台约束名，优先考虑配置伪造或确认依赖必要性。
Composer 无法真正“忽略扩展”——--ignore-platform-req 只能跳过扩展名检查，但不解决扩展缺失导致的运行时失败。
为什么 --ignore-platform-req 常被误用
很多人遇到 ext-redis 或 ext-gd 报错时直接加 --ignore-platform-req=ext-redis，以为装完就能跑。实际只是绕过了 Composer 安装前的校验，PHP 运行时仍会因扩展未启用而抛出 Class not found 或 Call to undefined function 错误。
-
--ignore-platform-req不影响 autoloader、不加载扩展、不修改php.ini - 它只对
composer install和composer update生效，对composer require同样有效 - 忽略后生成的
vendor/autoload.php仍会尝试加载依赖中声明的扩展相关类
--ignore-platform-req 的正确写法和常见变体
参数值必须严格匹配 composer.json 中 require 下的平台约束名（大小写敏感），不是扩展文件名或函数名。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 忽略单个扩展：
composer install --ignore-platform-req=ext-redis - 忽略多个扩展（重复使用参数）：
composer install --ignore-platform-req=ext-gd --ignore-platform-req=ext-mbstring - 忽略全部平台要求（危险！）：
composer install --ignore-platform-req（不带等号，跳过php、ext-*、lib-*全部检查） - 忽略 PHP 版本：
--ignore-platform-req=php（注意不是--ignore-platform-req=7.4）
比忽略更稳妥的替代方案
真要绕过扩展依赖，优先考虑配置层或代码层适配，而非压制警告。
- 确认包是否真的强依赖该扩展：有些包把
ext-xxx放在require里，其实只是可选功能，可改到require-dev或suggest - 用
platform配置伪造已安装（仅用于构建/CI）："config": { "platform": { "ext-redis": "5.3.0" } }—— 这会让 Composer 认为扩展存在，且不影响运行时 - 检查包文档：如
monolog/monolog对ext-amqp是可选的，不装也不报错；但laravel/octane强依赖ext-swoole，忽略后必然启动失败
最容易被忽略的后果
加了 --ignore-platform-req 后 composer install 成功，不代表项目能跑。尤其在 Laravel、Symfony 等框架中，服务提供者会在容器启动时检查扩展，此时才真正报错，堆栈远不如 Composer 报错直观。
本地开发用忽略可能侥幸通过，但部署到无该扩展的生产环境时，第一个 HTTP 请求就 500，而日志里只有模糊的 class not found —— 因为 Composer 没拦住，问题被延后了。
