Composer不安装PHP扩展，仅在install/update时校验ext-xxx是否启用；必须声明于require或require-dev中，扩展名须与php -m输出完全一致，版本约束无效，仅作存在性检查。
Composer 不会安装任何 PHP 扩展，只会在 composer install 或 composer update 时检查它们是否已启用；缺失就报错中断，不生成 autoload 文件。
ext-xxx 必须写在 require 或 require-dev 里
不是插件、不是约定，是 Composer 原生支持的伪包名机制。它只认 ext-xxx 这种格式，且必须放在 composer.json 的 require（生产必需）或 require-dev（仅开发用）字段中：
-
"ext-curl": "*"合法，"ext-curl": "^7.4"无效（版本号不指 cURL 库版本） -
"ext-mbstring": ""和"ext-mbstring": "*"等价，都表示“存在即可” -
"ext-intl": "^1.0"这类写法虽能解析，但实际校验时仍只调用extension_loaded('intl')，版本约束形同虚设 - 扩展名必须和
php -m输出完全一致：小写、无下划线、无后缀（如pdo_mysql，不是pdo-mysql或php-pdo-mysql）
报错信息明确，但容易误判为“Composer 没装好”
运行 composer install 时若缺失扩展，你会看到类似错误：
- Root package 'my/project' requires ext-gd (*), but it is not present.
这不是 Composer 自身问题，而是环境没配对。常见混淆点：
- 以为
composer require ext-gd能装扩展——不行，Composer 没这个能力 - 看到
ext-json报错，却去搜“如何用 Composer 安装 json”——PHP 8+ 内置，只需确认没被禁用（php.ini中没注释extension=json） - Docker 构建中先跑
composer install再装扩展——顺序反了，必须先RUN docker-php-ext-enable gd或apk add php82-gd，再执行 Composer
config.platform.ext-xxx 是“假装存在”，不是绕过检查
这个配置不是用来跳过校验的，而是让 Composer 在依赖解析阶段“按目标环境模拟可用扩展”。例如：
"config": { "platform": { "ext-igbinary": "3.2.14", "php": "8.1.28" } }
它的作用是：
- 告诉 Composer：“假设当前环境有 ext-igbinary 3.2.14”，从而影响哪些包会被选入
composer.lock - 如果真实环境没有该扩展，
composer install仍会失败——platform不压制运行时校验 - 适合 CI 场景：本地 PHP 8.3 有 ext-xdebug，但生产没有，又不想让 xdebug 相关包混进 lock 文件，就用
"ext-xdebug": "0"模拟“不存在”
真正容易被忽略的是：声明 ext-* 之后，你得确保部署流程里包含扩展安装/启用步骤。否则，composer install 成功了，php artisan serve 或 index.php 一跑就报 Call to undefined function curl_init()——那说明校验环节根本没触发，大概率是漏写了 ext-curl 声明，或者用了 --ignore-platform-reqs 却没意识到后果。
