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 <ext>确认扩展已加载且功能正常（例如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 的绿色输出。
