Composer check-platform-reqs：如何验证服务器环境是否满足项目需求？

composer check-platform-reqs 默认不报未启用扩展等隐性问题，需加 –no-dev –with-all-dependencies 参数并以目标 SAPI 用户运行；真要保稳，须结合 php -m、php –ri、最小脚本和 php -i 手动验证。

直接运行 composer check-platform-reqs 就能快速看到当前 PHP 环境是否满足 composer.json 中声明的平台依赖（比如 PHP 版本、扩展、INI 设置等），但它默认只检查“已安装但版本不匹配”的问题，**不会报错未启用的扩展**——这是最容易被忽略的坑。

为什么 check-platform-reqs 有时看起来“没报错”却部署失败？

这个命令只校验三类约束：

• PHP 版本（"php": "^8.1"）
• 已加载的扩展（如 "ext-mbstring": "*"）——但前提是该扩展在 php.ini 中已启用且能被 extension_loaded() 检测到
• INI 配置项（如 "config:memory_limit": "512M"）——仅检查当前运行时值，不校验 php.ini 文件是否设定了该值

它**完全不检查**以下情况：

• 扩展已编译但未在 php.ini 中启用（例如 extension=gd.so 被注释）
• 扩展虽启用，但依赖的系统库缺失（如 ext-gd 缺少 libpng，PHP 启动时不报错，但运行时图像函数失效）
• composer.json 里用的是 require-dev，而你执行时没加 --with-all-dependencies

如何让 check-platform-reqs 检出更真实的问题？

加参数组合使用，逼近生产环境行为：

• 用 --no-dev 排除开发依赖干扰（上线环境通常不装 require-dev）
• 加 --with-all-dependencies 强制递归检查所有依赖声明的平台要求（包括间接依赖里的 platform 字段）
• 在目标服务器上以**与 Web 服务相同的用户和 PHP SAPI 模式**运行（例如：Web 使用 php-fpm，就别用 CLI 的 php -v 判断；用 sudo -u www-data php -m | grep gd 确认扩展实际可用）

典型命令：

composer check-platform-reqs --no-dev --with-all-dependencies

比 check-platform-reqs 更可靠的验证方式

它只是静态检查，真要保稳，得补两步手动验证：

• 用 php -m 和 php --ri 确认扩展已加载且功能正常（例如 php --ri gd 输出中要有 GD Support => enabled）
• 写个最小验证脚本，调用关键函数（比如 laravel 项目必须有 mb_strlen('')、json_encode([])、openssl_encrypt()）
• 检查 phpinfo() 页面或 php -i | grep 'memory_limit|post_max_size'，确认 INI 值是运行时生效值，而非配置文件中的注释行

尤其注意 opcache.enable 这类开关型配置：它可能在 php.ini 里是 On，但 CLI 和 FPM 的 ini 文件不同，check-platform-reqs 只读当前 SAPI 的运行时值。

真正卡住部署的，往往不是 PHP 版本差 0.1，而是 ext-curl 没启、allow_url_fopen 被关、或者 date.timezone 没设导致 carbon 报错——这些都得靠组合验证，不能只信 check-platform-reqs 的绿色输出。