cli 环境未启用 mbstring 扩展——需通过 php -m | grep mbstring 验证，php --ini 查加载的 php.ini，php -r "var_dump(function_exists('mb_strlen'))" 确认函数是否存在，并按系统正确安装与启用对应版本扩展。
不是 Composer 有问题，而是你当前 CLI 环境的 PHP 没加载 mbstring 扩展——Web 页面能跑不代表命令行也能用。
怎么确认 CLI 真的没开 mbstring？
别信 phpinfo() 或浏览器里的结果，只看命令行输出：
- 运行
php -m | grep mbstring—— 如果没任何输出，说明 CLI 环境确实没启用 - 运行
php --ini—— 关注Loaded Configuration File那一行，它才是 CLI 实际读的php.ini - 运行
php -r "var_dump(function_exists('mb_strlen'));"—— 输出bool(false)就坐实了问题
Linux（Ubuntu/Debian）下快速修复
系统包管理器装扩展最稳，但必须版本对得上：
- 先查 CLI 的 PHP 版本：
php -v（比如显示PHP 8.2.10） - 装对应版本的扩展包：
sudo apt install php8.2-mbstring（不能只写php-mbstring，否则可能装到别的版本） - 强制启用 CLI 模块：
sudo phpenmod -v 8.2 mbstring（这步常被跳过，但 Ubuntu/Debian 必须做） - 验证：
php -m | grep mbstring应该立刻有输出
macOS（Homebrew）和 Windows 的典型坑
Homebrew 和 Windows 容易卡在“改了配置却无效”，核心是路径和加载顺序错乱：
- macOS：Homebrew 的
php.ini默认不自动扫描conf.d/目录。打开php --ini显示的主配置文件，确保里面有这行：scanpath = "/opt/homebrew/etc/php/8.3/conf.d"（路径按你实际版本调整） - Windows：检查
extension_dir是否指向正确的ext/目录；确认php_mbstring.dll文件真实存在；某些旧版 PHP 还要手动把libiconv.dll放到php.exe同目录 - 两者共性：改完配置后必须重启终端（尤其是 macOS 的 zsh/bash），否则
php命令可能还在用缓存的二进制或旧配置
为什么装了还报错？重点盯这三个地方
扩展文件存在、php.ini 里写了 extension=mbstring，但 Composer 还是报缺——大概率是下面某个环节断了：
-
php --ini显示的Scan for additional .ini files in路径下，没有包含mbstring.ini或类似配置文件 -
php -r "echo ini_get('extension_dir');"输出的路径下，找不到mbstring.so（Linux/macOS）或php_mbstring.dll（Windows） - 用了 Laragon、XAMPP 等一键环境，CLI 可能读的是单独的
php-cli.ini，而不是你正在编辑的那个php.ini
真正麻烦的从来不是“怎么装”，而是 CLI 和 Web 共用一个扩展名，却各自走不同的配置路径、不同的加载时机、甚至不同的 PHP 二进制——每次换环境都得重新 php --ini 一遍，别省这一步。
