需安装并启用 PHP mbstring 扩展：macOS 用 brew install php-mbstring，Linux 用 apt install php-mbstring，Windows 在 XAMPP/MAMP 中启用；确认 CLI 环境已加载，再运行 composer install。
composer install 时提示 ext-mbstring missing 怎么办
这是 composer 在检查运行环境扩展依赖时的硬性拦截，不是警告，是直接中断。它不关心你代码里有没有用到 mb_strlen，只看 composer.json 里声明的 ext-mbstring 是否在 PHP 当前配置中启用。
常见错误现象：Could not find package ... Your requirements could not be resolved to an installable set of packages. 或更直白的 The requested PHP extension mbstring is missing from your system。
- 先确认当前 CLI 使用的 PHP 版本和配置：运行
php -v和php -m | grep mbstring；注意 Web Server（如 Nginx/Apache）用的 PHP 配置可能和 CLI 不同，但 composer 只认 CLI 环境 - macOS（Homebrew）用户常漏掉：装了
php包但没装php-mbstring扩展包，需额外执行brew install php-mbstring，然后检查php.ini是否自动加载了extension=mbstring - Linux（Debian/Ubuntu）典型操作是
sudo apt install php-mbstring，但安装后要重启 PHP-FPM 或 Apache，否则php -m仍看不到 - Windows 用户若用 XAMPP/MAMP，请打开对应控制面板，勾选
mbstring并重启服务；不要手动改php.ini却忘记去掉;注释
为什么 composer.lock 里没有记录 ext-\* 的实际状态
composer.lock 只锁定包版本和哈希值，不记录宿主机扩展是否就绪。它假设你部署时的 PHP 环境满足 composer.json 中 require 下的 ext-* 声明——这个检查只发生在 install 或 update 阶段，且只在本地执行。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 这意味着：你可以在一台有
ext-mbstring的机器上生成composer.lock，然后把它推到 CI 或生产服务器；如果目标机缺失该扩展，composer install --no-scripts仍会成功（因为不校验扩展），但后续 PHP 运行时调用mb_*函数就会报致命错误 -
platform配置项（如"platform": {"php": "8.1.0", "ext-mbstring": "1.0.0"}）只是用来“欺骗” composer，让它跳过真实扩展检测，不能代替真实扩展存在；滥用会导致运行时崩溃 - CI/CD 流程中建议加一步验证：在
composer install后运行php -m | grep -E '^(mbstring|curl|json|openssl)$'，确保关键扩展就位
如何临时绕过 ext-\* 检查（仅限调试）
绕过不是解决，而是为了快速验证是否真由扩展缺失导致失败。生产环境严禁使用。
- 最常用的是
--ignore-platform-reqs：它跳过所有ext-*和php版本检查，命令为composer install --ignore-platform-reqs - 更精准的写法是只忽略某一个：比如只忽略 mbstring，用
--ignore-platform-req=ext-mbstring（注意等号，无空格） - 注意：这个参数不影响 autoloader 生成，也不影响后续 PHP 执行；一旦代码真调用了
mb_convert_encoding()，照样Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() - 如果你看到 “Class ‘Mbstring’ not found”，那大概率是拼错了类名——
ext-mbstring提供的是函数，不是类；别和symfony/string的Mbstring类混淆
ext-\* 声明写在 require 还是 require-dev
取决于扩展是否被运行时代码直接依赖。这关系到部署机器必须装什么，不是开发爽不爽的问题。
- 运行时必需（如 Laravel 的
config/app.php默认用mb_internal_encoding()）→ 写进require，上线机必须有 - 仅开发工具用（如
phpunit/phpunit内部用mb_*做字符串断言，但你的业务代码完全不碰）→ 可放require-dev，CI 和线上可不装 - 一个容易被忽略的点：某些包在
autoload的files里直接require了含mb_*调用的 PHP 文件，这种情况下即使你没显式调用，只要 autoloader 加载了那个文件，就立刻需要扩展存在
扩展依赖不是 composer 的“功能”，是它帮你守住的一道底线。越早发现缺失，越不容易在凌晨三点收到 500 页面报警。
