Composer报PHP扩展缺失错误是因CLI环境缺少对应扩展，需先确认composer调用的PHP路径及配置文件，再按系统正确安装并验证扩展可用性。
Composer 报 “The requested PHP extension xxx is missing” 不是你项目写错了，而是它在启动前就拒绝执行——因为当前 CLI 环境里压根没有 php -m 能列出的那个扩展。这不是 Composer 的限制，是它的安全机制：不让你在缺关键模块的环境下硬装，避免后续运行时崩溃。
先确认 composer 实际调用的是哪个 PHP
很多人改了 Apache 的 php.ini，终端里跑 composer install 还是一样报错，就是因为 CLI 和 Web 用的不是同一个 PHP 二进制和配置文件。
- 运行
composer diagnose，看输出里的 PHP binary 路径（比如/usr/bin/php或/opt/homebrew/bin/php） - 再用这个路径直接跑：
/usr/bin/php -m | grep intl（把intl换成你报错里的扩展名） - 同时执行
/usr/bin/php --ini，重点看 Loaded Configuration File 行——这才是你要改的php.ini
按系统装对扩展，别信“php -m 显示了就完事”
扩展名、包名、加载路径三者必须严格匹配，否则 php -m 里看不见，php -r "new ZipArchive();" 会直接 fatal error。
- Ubuntu/Debian：
sudo apt install php8.2-zip php8.2-mbstring php8.2-intl（版本号必须和php -v输出一致） - macOS Homebrew：
brew install php@8.2-zip php@8.2-intl，然后检查/opt/homebrew/etc/php/8.2/php.ini是否含extension="zip"；Homebrew 不自动加这行 - Windows：打开
php.ini（路径来自php --ini），取消;extension=php_zip.dll前的分号，并确认php_zip.dll真的存在于extension_dir指向的目录中 - Docker（Alpine）：
RUN apk add php82-zip php82-intl，不能只装php-zip，包名带版本号
验证扩展是否真可用，不止是“加载成功”
php -m | grep zip 有输出 ≠ ZipArchive 类能用。有些扩展加载了但 ICU 版本不兼容、libzip 太旧、或 DLL 缺依赖，会导致 Composer 静默失败。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
php -r "new ZipArchive();"—— 不报错才算真正可用 - 运行
php -r "echo INTL_ICU_VERSION;"，对比系统 ICU 版本（icu-config --version），主版本号必须一致（如都是 73） - 运行
php -r "echo ZIPARCHIVE::CHECKSUM_CRC32;"，能输出数字才说明 zip 扩展功能完整 - 如果用 Docker，确保基础镜像里装了
libzip-dev（构建时）和libzip（运行时）
离线或临时绕过时，别乱用 --ignore-platform-reqs
这个参数跳过所有平台检查，但不会让缺失的扩展突然变出来。代码里一旦调用 mb_strlen() 或 gd_info()，照样 fatal error。
- 只在纯离线部署脚本里用：
composer install --ignore-platform-reqs - 更稳妥的做法是在
composer.json里加"platform"配置，骗过当前项目检查，不影响其他项目 - CI/CD 中遇到 zip 缺失又没法装扩展？优先用
--prefer-source，但得确保所有依赖都有 Git 地址且可访问 - 千万别在
composer.lock已生成的环境里删vendor/后硬跑install——如果 zip 仍缺失，过程一样卡住
最常被跳过的动作是：没核对 php --ini 输出的 Loaded Configuration File 就去改错 php.ini；或者装了扩展却没验证 new ZipArchive() 是否真能实例化。这两步省掉，后面所有操作都是在给错误环境打补丁。
