composer install 报“无法满足依赖”但未明示缺失扩展，需用composer check-platform-reqs --no-dev命令一次性列出所有missing的ext-*项，或通过composer install -vvv | grep -a5 -b5 "ext-"提取详细报错。
Composer install 时 ext-* 报错但没提示具体缺哪个扩展
中文环境下 composer install 失败，报类似 Your requirements could not be resolved to an installable set of packages.，但错误里没写明缺哪个 ext-*，这是 Composer 默认不主动展开扩展依赖冲突导致的。它只告诉你“无法满足依赖”，不会像 Node.js 那样列出来哪个 ext-mbstring 没装。
真正有用的信息藏在 verbose 日志里：
composer install -vvv | grep -A5 -B5 "ext-"
或者更直接地，用 Composer 自带的诊断命令：
-
composer diagnose会检查已加载的扩展，但不验证composer.json中声明的ext-* -
php -m查当前启用的扩展列表，对照composer.json的require里所有ext-*项手动比对 - 把
composer.json中的ext-*提取出来，批量验证：
php -r "echo extension_loaded('mbstring') ? 'ok' : 'missing';"
中文系统下 php.ini 路径混乱导致 ext-* 实际未加载
Windows 中文版、macOS 中文用户名、Linux 下 locale 为 zh_CN.UTF-8 时，PHP 启动可能读错 php.ini 路径，尤其当配置中用了相对路径或中文注释干扰解析时。结果是：你明明在 php.ini 里写了 extension=mbstring，php -m 却不显示。
确认真实生效的配置文件位置：
php --ini
输出类似：
Configuration File (php.ini) Path: /usr/local/etc/php/8.2 Loaded Configuration File: /usr/local/etc/php/8.2/php.ini
重点看第二行 —— 这才是实际被加载的 ini 文件。常见陷阱：
- 多个
php.ini并存（如php.ini-development和php.ini-production），改错了文件 - 扩展配置写在了被
;include_path引入的子配置里，而该子配置路径含中文或权限不足，PHP 静默跳过 - Windows 下
extension_dir路径含中文，导致 DLL 加载失败（错误日志里会出现Unable to load dynamic library）
composer require 时 ext-* 不触发实时校验
composer require some/package 可能成功写入 composer.json，但不会立刻检查新包依赖的 ext-* 是否存在。直到下次 composer install 或 composer update 才爆错 —— 这对 CI/CD 或本地开发调试很不友好。
想提前预警，有两个实操办法：
- 加
--dry-run参数预检：composer require some/package --dry-run，它会模拟依赖解析，遇到缺失扩展会直接报错并指出是哪个ext-* - 用
composer check-platform-reqs（Composer 2.2+），它专为检测平台需求设计，输出清晰的缺失列表，例如：
ext-zip : missing (required by some/package)
注意：这个命令只检查当前 composer.lock 或 composer.json 中已声明的 ext-*，不会扫描新 require 的包的深层依赖 —— 所以建议在 require 后立即运行一次。
CI 环境里 ext-* 缺失却没报错，因为 PHP CLI 和 Web SAPI 加载的扩展不同
很多 CI 流程只跑 php -v 或 php -m，看起来扩展都齐了，但 composer install 仍失败。原因通常是：CI 使用的 PHP CLI 配置和 Web SAPI（如 Apache mod_php 或 PHP-FPM）分离，而 Composer 运行在 CLI 模式下，只认 CLI 的 php.ini。
典型表现：
- 本地
phpinfo()显示ext-redis已启用，但composer install报ext-redis missing - CI 日志里
php -m | grep redis为空，但你确实在/etc/php/8.2/apache2/php.ini开了扩展 —— CLI 模式根本没读这个文件
解决方式只有两个：
- CI 脚本里明确指定 CLI 的 ini 路径：
php -c /etc/php/8.2/cli/php.ini -m - 在 CI 配置中统一启用扩展（如 GitHub Actions 用
shivammathur/setup-php时，必须显式传参extensions: [mbstring, zip, gd]）
最易忽略的一点：某些扩展（如 ext-sodium）在 PHP 7.2+ 是内置的，但若编译时没带 --with-sodium，CLI 和 Web SAPI 都可能缺失 —— 此时 php -r "var_dump(function_exists('sodium_crypto_box'));" 比查 php -m 更可靠。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
