需确认Composer所用PHP的CLI配置及扩展真实启用状态：先用php -i查Loaded Configuration File路径和php -m看已启扩展，注意CLI与Web配置分离、扩展名平台差异、opcache须用zend_extension、intl等依赖系统库，最后用composer diagnose -v验证。
检查 php.ini 中扩展是否真的启用
Composer 报错 The requested PHP extension is missing 时，第一反应常是“已装扩展”，但实际可能是 php.ini 没生效或加载路径不对。重点确认两点：当前 Composer 使用的 PHP 是哪个、它读的是哪份 php.ini。
- 运行
php -i | grep "Loaded Configuration File"查看实际加载的php.ini路径（注意：不是php --ini显示的所有路径，而是Loaded Configuration File行） - 用
php -m看已启用的扩展列表，确认目标扩展（如mbstring、curl、openssl）是否在其中 - 若扩展名出现在
php.ini的extension=行但未生效，检查该行是否被注释（开头有分号;），以及扩展文件（如php_mbstring.dll或mbstring.so）是否真实存在于extension_dir指向的目录下
区分 CLI 和 Web Server 的 PHP 配置
Composer 运行在 CLI 模式下，它用的是 CLI 版本的 PHP 配置，和 Apache/Nginx 的 PHP 配置完全独立。即使网页能跑 phpinfo() 显示扩展已启用，CLI 下仍可能缺失。
- 执行
which php和php -v，确认你调用的php是预期版本（例如不是 Homebrew、Docker、XAMPP 自带的多个 PHP 共存导致混乱） - 对比
php -i | grep "Configuration File"和 Web 环境中phpinfo()输出的配置路径——它们大概率不同 - 常见陷阱：用
sudo apt install php-mbstring安装后，CLI 的php可能仍指向旧版本（如/usr/bin/php），而新扩展只装到了/usr/lib/php/*/下对应新版的目录，导致找不到
扩展名拼写与平台差异（Linux/macOS/Windows）
扩展名在不同系统上不一致，composer.json 或 php.ini 写错会导致“找不到”。Composer 校验时只认扩展的逻辑名（如 mbstring），但底层加载依赖文件名和平台。
Software Data Github Interact Developer Helper
下载
帮助用户满足已验证需求：代理用户在Clawhub上对GitHub式工作流有强烈需求，需要实用帮助修复bug、强化设置。
- Linux/macOS：
extension=mbstring.so（不能写成php_mbstring.so，除非模块名如此） - Windows：
extension=php_mbstring.dll（注意前缀php_和后缀.dll） - PHP 8+ 启用
opcache时，需确保zend_extension=opcache.so（不是extension=），否则会静默失败 - 某些扩展（如
intl）依赖系统库（libicu），仅启extension=intl不够，还需验证php -r "echo INTL_ICU_VERSION;"是否报错
验证 Composer 实际检测到的环境
Composer 在安装前会调用 composer diagnose 做自检，它比人工判断更贴近真实执行上下文。
立即学习“PHP免费学习笔记（深入）”；
- 运行
composer diagnose -v（加-v显示详细扩展检查过程），它会逐条列出“Checking platform settings”、“Checking git settings”等，并明确指出缺失的扩展名 - 如果
diagnose提示ext-zip缺失，但php -m | grep zip有输出，说明 Composer 检测的是另一个 PHP 实例——此时应检查COMPOSER_HOME或PHP_IDE_CONFIG等环境变量是否干扰了 PHP 查找路径 - 临时绕过检查（不推荐）可用
composer install --ignore-platform-reqs，但这只是掩耳盗铃；真正要解决的是环境一致性问题
php -r "var_dump(get_loaded_extensions());"
这行命令能快速列出当前 CLI PHP 加载的所有扩展，比 php -m 更可靠（后者可能受别名或包装脚本影响）。复杂点在于：PHP 多版本共存 + 扩展编译参数差异 + ini 文件层级覆盖（conf.d/ 目录下的额外配置），最容易被忽略的是「你以为 reload 了 Apache，其实没重启 PHP-FPM 进程」这类低级但高频的问题。
