composer check-platform-reqs --no-dev 是定位 PHP 扩展缺失最直接有效的命令，它不安装、不修改依赖，只做一次干净的环境快照校验，比反复看 composer install 的报错堆栈更省时间。
composer check-platform-reqs --no-dev 是定位 PHP 扩展缺失最直接有效的命令，它不安装、不修改依赖，只做一次干净的环境快照校验，比反复看 composer install 的报错堆栈更省时间。
为什么 check-platform-reqs 比看 install 报错更准
Composer 在 install 或 update 过程中一旦遇到第一个 platform 不满足项（比如 ext-gd 缺失），就可能中断并停止检查后续依赖——你看到的只是“第一个失败”，不是“全部缺失”。而 check-platform-reqs 会强制遍历所有 require 和 config.platform 声明的扩展、PHP 版本、INI 设置，并统一标出 MISSING 或 OK。
- 它能暴露被
config.platform.ext-xxx“假装存在”但实际没装的扩展（例如 CI 配置里写了"ext-intl": "8.1.0"，但镜像里根本没装 intl） - 它不依赖当前 lock 文件状态，哪怕
vendor/是空的也能跑 - 加
--no-dev后只检查运行时刚需，避免开发用扩展（如ext-xdebug）干扰判断
check-platform-reqs 显示 MISSING 却 php -m 能看到扩展
典型现象是命令输出 ext-mbstring MISSING，但执行 php -m | grep mbstring 确实有结果。这几乎一定是 CLI 和 Web 使用了不同 php.ini，而 Composer 只认 CLI 的配置。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先跑
php --ini，确认Loaded Configuration File路径，别改错文件 - 检查该
php.ini是否真启用了扩展：搜索extension=mbstring（Linux/macOS）或extension=php_mbstring.dll（Windows），确保没被注释且路径正确 - CentOS/RHEL 上常见情况：
php-xml包已装，但dom和simplexml没自动启用，需手动在/etc/php.d/下建15-dom.ini，内容仅一行：extension=dom - Docker 用户注意：
apk add php82-mbstring后，Alpine 默认不自动写 ini，得自己加RUN docker-php-ext-enable mbstring
报 ext-intl MISSING 但 php -i | grep ICU 有输出
这是 ICU 版本不匹配导致的静默失效。PHP 编译时绑定的 ICU 库主版本（如 72）和系统运行时提供的（如 74）不一致，intl 扩展虽能加载，但 intl_is_failure() 返回 true，触发 Composer 校验失败。
立即学习“PHP免费学习笔记（深入）”；
- 查 PHP 实际绑定的 ICU 版本：
php -r "echo INTL_ICU_VERSION;" - 查系统 ICU 版本：
icu-config --version（Linux）或pkg-config --modversion icu-i18n - macOS Homebrew 用户：若
brew upgrade icu4c后出问题，重装 PHP 是最稳方案：brew reinstall php - 临时绕过仅限调试：
composer check-platform-reqs --ignore-platform-reqs=ext-intl，但别提交到 CI
真正麻烦的不是“没装扩展”，而是“装了但没对上 CLI 的配置路径”，或者“扩展加载了但底层依赖（如 ICU）版本打架”。check-platform-reqs 只告诉你“缺”，不告诉你“为什么缺”——得靠 php --ini 和 php -r 这类命令一层层剥开看。
