Composer报错找不到PHP扩展（如ext-mbstring）而php -m已显示加载，本质是Composer调用的PHP二进制与当前CLI环境不一致，需通过composer diagnose确认“PHP binary”路径，并检查该PHP对应的php --ini及php -m输出，而非仅依赖php -v或全局php -m。
Composer 报错说找不到某个 PHP 扩展（比如 ext-mbstring、ext-xml），但你确认本地 php -m 已加载——大概率是 Composer 在读取一个被“锁死”的 PHP 配置，而非你当前 CLI 使用的 PHP。
Composer 用的是哪个 PHP？
Composer 是个 PHP 脚本，它运行时依赖系统中实际执行的 php 命令。但很多开发环境（尤其是 Docker、Laravel Sail、某些 IDE 内置终端）会悄悄切换 PATH 或使用 wrapper 脚本，导致：
• php -v 显示的是你期望的版本
• 但 composer diagnose 或 composer install 实际调用的却是另一个 PHP（比如系统自带的老版本，或容器里未启用扩展的版本）
验证方式：
• 运行 which php 和 composer config --global --list | grep -i php
• 更可靠的是直接看 Composer 启动时用的解释器：head -1 $(which composer) —— 如果第一行是 #!/usr/bin/env php，那它就完全取决于当前 shell 的 php；如果是硬编码路径（如 #!/usr/local/bin/php），就得去那个路径下查扩展
常见镜像/容器环境下的扩展缺失
Docker 官方 php:8.2-cli 镜像默认只装最精简扩展，mbstring、xml、zip、pdo 全都不在默认安装列表里。Laravel Sail 的 Dockerfile 通常会补一些，但如果你自己改过基础镜像或用了 Alpine 版本，问题更明显。
立即学习“PHP免费学习笔记（深入）”；
解决方法（以 Debian/Ubuntu 系为基础镜像为例）：
• 在 Dockerfile 中加装扩展：RUN apt-get update && apt-get install -y libzip-dev && docker-php-ext-install mbstring xml zip pdo pdo_mysql
• 注意顺序：先装系统依赖（如 libzip-dev），再 docker-php-ext-install，否则会编译失败
• Alpine 用户请换用 apk add php82-mbstring php82-xml 等对应包名，别硬套 Debian 命令
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
Windows WSL 或 MAMP/XAMPP 下的 PATH 冲突
Windows 上多个 PHP 环境共存时（例如：Composer 自带的 PHP、XAMPP 的 PHP、WSL 里的 PHP），composer 命令可能被注册为 Windows 的批处理脚本（composer.bat），它内部硬编码调用 C:\ProgramData\ComposerSetup\bin\php.exe —— 这个 PHP 很可能没装任何扩展。
快速判断和修复：
• 运行 where composer 和 where php，看是否指向不同目录
• 直接删掉 C:\ProgramData\ComposerSetup\bin\php.exe（或重命名），让 composer 回退到系统 PATH 中的 php
• 或者彻底卸载 ComposerSetup，改用 curl -sS https://getcomposer.org/installer | php 方式安装成纯 PHAR 文件，它会严格跟随当前 php 环境
为什么 composer show --platform 显示的扩展和 php -m 不一致？
composer show --platform 读取的是 Composer 当前运行时的 get_loaded_extensions() 结果，不是你手动敲 php -m 那个 PHP。两者不一致，说明 Composer 没有运行在你认为的那个 PHP 下。
关键点：
• 不要只信 php -v，要信 php -r "print_r(get_loaded_extensions());" 的输出
• 如果你在 IDE 终端里跑 Composer，试试在纯系统终端（CMD/PowerShell/Terminal.app）里重试，排除 IDE 插件劫持 PATH 的可能
• composer diagnose 最后一行会明确写出 “PHP binary” 和 “PHP version”，这是唯一可信依据
最常被忽略的一点：有些 CI 环境（GitHub Actions、GitLab CI）的 PHP setup 步骤默认不启用常用扩展，得显式加 extensions: [mbstring, xml, zip] 参数，否则 composer install 会在平台检查阶段直接失败，而不是等到真正用到扩展时才报错。
