composer check-platform-reqs不是万能检查，仅比对composer.json中显式声明的PHP版本与扩展和当前CLI环境是否匹配；未声明不查，声明但未启用则报missing，且不验证Web环境、底层库或运行时功能。
composer check-platform-reqs 不对比“本地环境是否万无一失”，它只做一件事：拿当前 CLI 环境的 PHP 版本和已加载扩展，去比对 composer.json 里 require 和 config.platform 中**显式写死的平台约束**。没写 = 不查，写了但环境不满足 = 报 missing。
为什么 check-platform-reqs 显示 missing，但 php -m 能看到扩展？
根本不是扩展没装，是 Composer 和你敲 php -m 用的不是同一个 PHP 二进制文件。
- 运行
which php查你终端默认的 PHP 路径，再用这个完整路径执行/opt/homebrew/bin/php -m | grep zip（macOS）或/usr/bin/php -m | grep zip（Linux），必须一致 - macOS 上 Homebrew 安装的 PHP 常被系统自带旧版覆盖 PATH；Windows 上注意
C:\php\php.exe和C:\xampp\php\php.exe可能共存 - 确认 Composer 实际调用的是哪个 PHP：
composer config --global bin-dir或看php -i | grep "Loaded Configuration File"输出的配置文件路径
加 --lock 参数才真正反映生产环境
不加 --lock，它只读 composer.json；加了，它才去解析 composer.lock 里所有已安装包的精确版本，并检查这些包实际运行时需要什么 —— 比如某 v2.5.0 的包悄悄要求 ext-gmp，而 v2.4.0 不要，不加 --lock 就完全看不见。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- CI/CD 部署前必须加
composer check-platform-reqs --lock，否则上线后可能报Call to undefined function gmp_init() - 本地切换 PHP 版本后（比如从 8.1 升到 8.3），
--lock能立刻暴露ext-apcu missing这类问题 - 它不下载、不解析依赖图、不写任何文件，毫秒级完成，是最后一道轻量兜底检查
check-platform-reqs 报 OK ≠ 项目能跑
它只告诉你“声明的约束是否满足”，不是“代码能不能跑”。很多崩溃点它压根不碰：
- 代码里硬调用了
openssl_encrypt()，但composer.json没写"ext-openssl": "*"→ 完全沉默 - CLI 环境通过，Web 环境（PHP-FPM/Nginx）没启用同名扩展 → 它不管 Web
- 扩展虽加载，但底层库缺失（如
ext-intl缺 ICU）→ 运行时仍崩 -
config.platform写错字段名（比如"platfrom"）→ 静默忽略，检查失效
真正容易被忽略的是：它不校验运行时实际功能，只做 extension_loaded() 和版本字符串比对。上线前别只信它输出的 OK。
