Composer报错ext-mbstring或ext-xml缺失，需先确认PHP CLI配置中对应扩展是否启用：Linux/macOS检查php.ini中extension=mbstring是否取消注释，Windows检查php_mbstring.dll路径及extension_dir，Docker需安装对应系统包并重启服务。
Composer 报错 ext-mbstring 或 ext-xml 缺失怎么办
Composer 启动时直接报错，比如 Your requirements could not be resolved，或更明确地提示 The requested PHP extension mbstring is missing from your system —— 这不是 Composer 本身坏了，而是它检测到当前 PHP 环境缺关键扩展，拒绝继续执行。
这类错误常见于新装 PHP（尤其是手动编译或 Docker 镜像精简版）、macOS 上用 Homebrew 安装后未启用扩展、或 Windows 下 php.ini 没配对的情况。
- 先确认你实际在用哪个 PHP：运行
which php和php -v，再跑php -m | grep mbstring（把mbstring换成报错里提到的扩展名）；别只看phpinfo()页面，CLI 和 Web SAPI 的配置可能不同 - Linux/macOS：扩展通常以
.so文件存在，需确保extension=mbstring这行在 CLI 用的php.ini里已取消注释；用php --ini查明 CLI 加载的是哪个配置文件 - Windows：检查
php.ini中是否有extension=php_mbstring.dll，且extension_dir指向正确的ext/目录；注意 DLL 文件名是否带版本号（如php_mbstring.dll而非php_mbstring7.dll） - Docker 用户容易漏掉：Alpine 镜像需
apk add php7-mbstring（注意包名带7或8），Debian/Ubuntu 则是apt install php-mbstring，装完还得重启 PHP-FPM 或 Apache
PHP 8.2+ 提示 ext-intl 不可用，但 php -m 显示已加载
这通常是 ICU 版本不兼容导致的静默失败：PHP 编译时绑定的 ICU 库版本，和运行时系统提供的不一致，intl 扩展虽能加载，但 Composer 在验证时调用 intl_is_failure() 会返回 false，触发“缺失”误判。
典型现象是 composer diagnose 报 The requested PHP extension intl is missing，而 php -i | grep ICU 却显示版本信息。
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查实际 ICU 版本：运行
php -r "echo INTL_ICU_VERSION;"，再对比系统 ICU 版本（icu-config --version或pkg-config --modversion icu-i18n） - 常见坑：macOS Homebrew 更新了
icu4c，但 PHP 是旧版编译的，二者主版本不匹配（如 PHP 编译用 ICU 69，系统升到了 73） - 临时绕过（仅调试）：加
--ignore-platform-req=ext-intl，但别提交到 CI 或生产环境 - 根治办法：重装 PHP（Homebrew 用
brew reinstall php；Docker 改基础镜像或加构建参数；源码编译则需--with-icu-dir=/usr/local/opt/icu4c显式指定路径）
为什么 composer install 有时不报扩展缺失，有时又报
不是 Composer 变严格了，而是它依赖 composer.json 里的 require 和 platform 配置做校验。同一份代码，在不同机器上表现不同，往往是因为平台约束没对齐。
例如项目声明了 "ext-gd": "*"，但你的 PHP 没开 GD；或者 "php": "^8.1"，而你本地是 8.0 —— 这些都会被 composer install 拦住，但 composer update 可能跳过（取决于 lock 文件状态）。
- 检查项目是否设了
config.platform：运行composer config platform，如果输出里有ext-mbstring等条目，说明项目强制要求这些扩展，哪怕你本地 PHP 有，也会按这个配置校验 -
composer install默认读composer.lock，只要 lock 文件里记录的包兼容当前环境，就不深检扩展；但一旦 lock 文件不存在或过期，就会走完整平台校验 - CI 环境常禁用扩展校验（
--ignore-platform-reqs），但这掩盖问题；更稳妥的是在 CI 配置里显式安装对应扩展，比如 GitHub Actions 中加sudo apt-get install php8.2-mbstring
Mac M1/M2 上用 Rosetta 运行 PHP 导致扩展加载失败
ARM 原生 PHP 和 x86_64 架构的扩展二进制不兼容，强行混用会报 Invalid ELF header 或直接静默跳过扩展加载 —— Composer 就当它不存在。
尤其常见于通过 Homebrew 安装了 php@8.2（ARM），但某些扩展（比如老版本 pdo_pgsql）还是 x86 编译的，或你手动下载了 Intel 版 .so 文件。
- 确认架构：运行
file $(which php)和file /opt/homebrew/lib/php/pecl/20220829/pdo_pgsql.so（路径依实际调整），看是否都是arm64 - Homebrew 用户优先用
brew install php@8.2全套安装，别单独brew install php@8.2-pgsql（后者已废弃）；新版会自动拉取匹配架构的 PECL 包 - 如果必须用 Intel 工具链，统一切到 Rosetta 终端，再重装 PHP 和所有扩展；但性能有损耗，且未来会被逐步放弃
- PHP 8.3+ 开始对 ARM 兼容性更好，若项目允许，升级 PHP 版本比硬调兼容更省事
最麻烦的不是找不到扩展，而是扩展加载了但功能残缺——比如 mbstring 缺少 mbregex 支持，或 intl 的 Locale::parseLocale() 返回空。这些不会让 Composer 报错，却会让 Laravel、Symfony 在运行时崩。真要排查，得进 vendor 里看具体包的 composer.json，它写的 ext-xxx 要求，有时候比表面看到的更细。
