Composer报错因PHP扩展缺失或版本不匹配，需先用php -m确认实际加载的扩展，再通过config.platform声明或修正PHP配置解决，而非仅跳过检查。
Composer 报错提示包版本不满足 PHP 扩展要求，本质是 composer install 或 composer update 过程中触发了对扩展（如 ext-gd、ext-mbstring）的硬性依赖检测，而当前 PHP 环境缺失或版本不匹配。解决的关键不是跳过检查，而是让 Composer「看清」你实际启用的扩展，或明确告知它哪些扩展不可用但可接受。
确认当前 PHP 实际加载的扩展列表
Composer 检测的是 php -m 输出的已启用模块，不是 php.ini 里写了但没生效的配置。常见误区是改了 php.ini 却忘了重启 PHP-FPM 或 Web 服务器，或 CLI 和 CGI 使用了不同配置文件。
- 运行
php -m | grep -E 'gd|mbstring|curl|xml|json|openssl'查看核心扩展是否在列 - 对比
php --ini显示的配置路径，确认你编辑的是 CLI 模式下生效的php.ini - 若用 Docker，需进入容器执行上述命令；若用 XAMPP/MAMP，注意 CLI 默认可能调用系统自带 PHP
强制指定 PHP 扩展状态绕过检测（临时调试用）
某些包（如 symfony/console v6+）会通过 ext-* 声明 require，但你的环境确有该扩展却因动态加载失败未被识别。此时可用 --ignore-platform-req 或更精准的 --ignore-platform-req=ext-gd 跳过单个扩展检查。
composer install --ignore-platform-req=ext-gd --ignore-platform-req=ext-mbstring
⚠️ 注意：这不是修复，只是掩盖问题。生产环境应优先解决扩展加载本身，而非跳过验证。
立即学习“PHP免费学习笔记（深入）”；
在 composer.json 中声明平台配置（推荐长期方案）
如果你确定某扩展在部署环境一定存在（比如 Dockerfile 中已 docker-php-ext-install gd），但本地开发机暂缺，可在项目 composer.json 的 config.platform 下显式声明，让 Composer 安装时「假装」这些扩展已就绪：
{
"config": {
"platform": {
"php": "8.2.10",
"ext-gd": "8.2.10",
"ext-mbstring": "8.2.10",
"ext-xml": "8.2.10"
}
}
}这样既避免 --ignore-platform-req 的全局风险，又能让锁文件（composer.lock）记录一致的平台假设，多人协作更可控。
检查 vendor/bin 目录下工具的 PHP 解释器路径
有些项目通过 vendor/bin/phpunit 或 vendor/bin/psalm 启动时仍报扩展缺失，是因为这些脚本默认调用 #!/usr/bin/env php，可能指向错误的 PHP 版本。可手动指定：
- 临时：运行
php8.2 vendor/bin/phpunit - 永久：修改脚本首行（如
#!/usr/bin/env php8.2），或设置alias phpunit='php8.2 vendor/bin/phpunit' - 更稳妥：用
composer exec -- php -v验证执行时实际使用的 PHP 路径
扩展检测失效最常发生在多 PHP 版本共存场景，别只查 php -v，要查所有相关命令背后真正调用的是哪个 php。
