Composer卡在ext-*报错，是因为它严格校验composer.json中声明的PHP扩展是否已在CLI环境加载，未找到即中断；需按系统规范安装并启用对应扩展，如Ubuntu执行sudo apt install php-gd，再用php -r "var_dump(extension_loaded('gd'));"验证返回bool(true)。
Composer 不会自动安装或启用 PHP 扩展，它只检查、报错、并强制你面对环境问题——这是设计使然，不是缺陷。
为什么 composer install 会卡在 ext-* 报错？
因为 Composer 在解析依赖时，会逐条比对 composer.json 中 require 下的 ext-xxx 条目（如 ext-curl、ext-gd），然后调用 php -m 检查当前 PHP CLI 环境是否已加载对应扩展。只要没找到，就中断安装，并输出类似：
Problem 1 - Root composer.json requires ext-gd * but it is missing from your system.
这不是“网络问题”或“权限问题”，而是环境能力缺失的明确信号。
- 报错里的
ext-gd是严格匹配扩展名，不是包名（php-gd是 Debian 包名，gd是 Windowsphp.ini中的 extension 名） - 版本约束（如
"ext-gd": "^3.0"）只在扩展自身提供PHP_VERSION_ID或GD_VERSION常量时才生效；多数情况下*就够用 - 如果你用的是 Docker 或多 PHP 版本共存环境（如 phpbrew），务必确认
composer命令调用的是目标 PHP 二进制文件：php8.1 $(which composer) install
如何让 ext-* 检查通过？三类真实场景应对
不能跳过，但可以精准干预：
立即学习“PHP免费学习笔记（深入）”；
-
Linux（apt/dnf）：运行
sudo apt install php-gd（Ubuntu）或sudo dnf install php-gd（Fedora），它会自动写入/etc/php/*/mods-available/gd.ini并启用 -
macOS（Homebrew）：按 PHP 版本安装，例如
brew install php@8.2-gd，装完需确认php -i | grep "gd support"输出为enabled -
Windows / 自编译 PHP：打开
php.ini，取消注释extension=gd（注意不是php_gd.dll），确保extension_dir指向正确的ext/目录，重启 Web 服务或 CLI
验证是否真正生效，别信配置文件，跑这行命令：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
php -r "var_dump(extension_loaded('gd'));"输出 bool(true) 才算过关。
platform 配置不是绕过检查，而是切换“检查对象”
当你在 CI 构建机上没有 ext-gd，但生产服务器有，又不想本地开发环境降级——这时该用 config.platform，而不是 --ignore-platform-reqs：
{
"config": {
"platform": {
"php": "8.1.25",
"ext-gd": "8.1.25"
}
}
}它的作用是告诉 Composer：“请假装 ext-gd 已存在且版本是 8.1.25”，从而让依赖解析阶段能选到兼容版本；但它不改变实际运行环境，也不安装扩展本身。
- 这个配置只影响
composer install时的版本决策，不影响运行时行为 - 如果生产环境真没启 ext-gd，哪怕 lock 文件里锁了 8.1 兼容包，上线后照样报
Class 'GdImage' not found - CI 脚本中应配合使用
--no-dev --optimize-autoloader，而非加--ignore-platform-req=ext
私有插件 + ext-* 依赖 = 双重验证陷阱
如果你 require 的是一个私有 Composer 插件（"type": "composer-plugin"），而它自己又声明了 "ext-imagick": "*"，那么你会遇到两层校验：
- 第一层：Composer 安装该插件前，先检查你本地是否满足
ext-imagick - 第二层：插件的
activate()方法在composer update时被调用，可能再次检查（取决于插件实现）
此时若漏掉 repositories 配置，composer require vendor/private-plugin 会直接失败，报 Could not find package；就算配了 repositories，也得先搞定 ext-imagick 才能走到插件激活那步。
最容易被忽略的是：插件的 activate() 逻辑可能依赖扩展，但 composer install 不触发它——所以你在 CI 里跑 install 看不出问题，一到 update 或本地调试就崩。别假设“装上了就等于可用”。
