应使用--ignore-platform-req=ext-xxx精准跳过单个扩展检查，参数须严格匹配composer.json中require键名、大小写敏感且不可省略ext-前缀；忽略多个需重复书写该参数。
composer install 卡在 ext-xxx 缺失报错，但你确定不需要它
这不是 Composer 本身卡住，而是平台校验环节的硬拦截。只要 composer.json 的 require 或依赖包中声明了 ext-xxx，Composer 就会在解析完依赖树后、真正下载前强制检查该扩展是否已加载——哪怕代码里根本没用到它。
常见现象包括：Problem 1 - Root composer.json requires ext-igbinary * but it is missing from your system.，尤其在 CI/CD 构建镜像中高频出现。
- 只跳过单个扩展：加
--ignore-platform-req=ext-igbinary - 跳过多个扩展：重复参数，如
--ignore-platform-req=ext-gd --ignore-platform-req=ext-curl - 不推荐用
--ignore-platform-reqs：它会同时绕过 PHP 版本、所有扩展、lib 库检查，风险不可控 - 这个参数不影响运行时行为——
new Redis()还是会报错，它只让 Composer 走完安装流程
为什么关掉 Xdebug 能让 Composer 解析快 3 倍以上
Xdebug 不是“慢”，是它在 Composer 的 Resolving dependencies 阶段疯狂刷盘：为每个 autoloaded 类、每个 ReflectionClass、每个 require 注入钩子并记录调用栈。一旦内存压力上升或 xdebug.mode 非 off，它就会把中间状态写成临时 trace 文件，触发大量小文件随机读写。
iostat -x 1 可见磁盘 %util 持续 90%+，而关掉后回落到 5–10%——这不是错觉，是 I/O 放大。
- 验证是否加载：
php -m | grep -i xdebug或php -v | grep -i xdebug - 临时关闭（Xdebug 3.1+）：
XDEBUG_MODE=off composer update --dry-run - 更彻底的方式：
php -d zend_extension= -d extension= $(which composer) install（清空 zend 扩展比设xdebug.mode=off更可靠） - 别信“只设
xdebug.mode=off就够了”——只要扩展被加载，钩子就存在
config.platform 伪造扩展 vs 命令行参数，哪个更合适
两者都是绕过校验，不是解决缺失。区别在于作用域和可维护性。
-
config.platform写在composer.json里，比如"ext-gd": "1.0"，对所有命令生效，适合团队统一开发环境模拟 - 命令行参数如
--ignore-platform-req=ext-gd只影响当前执行，适合 CI/CD 构建、本地临时调试 - 伪造扩展不会让
extension_loaded('gd')返回 true，运行时仍需真实环境支持 - 若项目用到了
ext-amqp但只是 Monolog 的可选通道，精准忽略比全局伪造更贴近实际需求
加了 --no-scripts 为什么还是过不了 ext 检查
--no-scripts 只禁用 scripts 字段定义的钩子（如 post-install-cmd），和平台校验完全无关。校验发生在依赖解析之后、脚本执行之前，属于 Composer 安装流程的硬性前置步骤。
如果你加了 --no-scripts 仍失败，说明问题不在脚本，而在平台校验本身。
- 常见诱因：
ext-igbinary在旧版 PHP 上加载失败后 hang 住，或disable_functions禁用了shell_exec导致内部调用失败 - 此时唯一有效解法仍是
--ignore-platform-req=ext-xxx，或手动删掉引发问题的platform声明项 - 不要指望
--no-plugins或--no-cache能绕过这一层
真正的瓶颈往往藏在看不见的地方：Xdebug 的钩子、平台校验的硬拦截、扩展加载失败后的静默 hang。这些点不解决，光调 memory_limit 或换镜像源没用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
