composer check-platform-reqs 是唯一直接校验当前 cli php 环境是否满足 composer.json 中平台约束的命令，它仅比对不安装、不写锁、不猜测，但需注意 php 二进制路径一致性、config.platform 的模拟干扰、ext- 前缀强制要求、--with-dependencies 补充依赖检查及退出码判断。
composer check-platform-reqs 是唯一能直接告诉你「当前 CLI PHP 环境是否满足 composer.json 里白纸黑字写的平台约束」的命令——它不装包、不写锁、不猜，只比对。
为什么它报错但 php -m 显示扩展已加载？
根本不是扩展没装，而是 composer 和你敲 php -m 用的不是同一个 PHP 二进制。
- 执行
which php和composer config --global bin-dir，确认 Composer 启动时实际调用的是哪个php - 用完整路径复现检查：
/opt/homebrew/bin/php -m | grep zip（macOS）、C:\php\php.exe -m | findstr gd（Windows） - 运行
/opt/homebrew/bin/php -r "var_dump(extension_loaded('gd'));"直接验证该 PHP 是否真加载了扩展 - 临时删掉
composer.json中的"config": {"platform": {...}}段，避免“假装环境”干扰判断
composer.json 里写了 "php": "^8.2"，但本地是 8.3，为啥还 FAIL？
不是版本太高，而是你项目里可能写了 "config": {"platform": {"php": "8.2.0"}} —— 这个字段会让 check-platform-reqs 强制按“假版本”校验，无视你 php -v 输出的真实值。
-
config.platform.php是模拟行为，适合 CI 构建，不适合本地开发验证 - 开发时建议删掉整个
config.platform块，让检查基于真实环境 - 如果必须保留，可用
composer check-platform-reqs --platform=php:8.3.0覆盖它 - 注意拼写：写成
"platfrom"或"platforms"会被静默忽略，不报错也不检查
没报错，项目却启动就 Fatal error: Uncaught Error: Call to undefined function openssl_encrypt()
check-platform-reqs 只看 composer.json 的 require 和 require-dev 字段里明确声明的 ext-*，不扫描代码。
- 漏写
"ext-openssl": "*"→ 它完全不管，直到运行时炸 - 扩展名必须带
ext-前缀，写成"openssl": "*"会被跳过 - 某些包把依赖藏在
conflict或provide里，这个命令不读这些字段 - 想提前暴露这类问题，可加
--with-dependencies让它读composer.lock，但更可靠的做法是跑一次composer install --dry-run
CI/CD 里怎么用才不踩坑？
它适合放在 composer install 前做快速守门，但必须确保执行环境和最终运行环境一致。
- CI 脚本中先确认
php -v和which php输出，再跑composer check-platform-reqs --no-dev -
--no-dev很关键：跳过require-dev，只验生产依赖，避免测试工具污染判断 - 不要依赖
composer diagnose：它只查 Composer 自身能否启动，完全不碰 PHP 版本或扩展 - 退出码为 1 表示失败，可直接
|| exit 1终止流水线
php.ini 里的运行时配置（比如 memory_limit、max_execution_time），也不管 Web 和 CLI 加载的是不是同一份 php.ini。验证完 check-platform-reqs，还得单独跑 php --ini 和 php -r 'var_dump(ini_get("memory_limit"))'。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
