Composer check-platform-reqs如何运行_Composer兼容性检测说明
你可能会觉得,跑一遍 composer check-platform-reqs 没报错,项目就铁定稳了?实际上,这个命令只盯着当前项目根目录下 composer.json 里 require 和 config.platform 显式声明的 PHP 版本与扩展,完全不管那些没声明的依赖、Web 环境、
你可能会觉得,跑一遍composer check-platform-reqs没报错,项目就铁定稳了?实际上,这个命令只盯着当前项目根目录下composer.json里require和config.platform显式声明的 PHP 版本与扩展,完全不管那些没声明的依赖、Web 环境、php.ini设置,更不会去检查代码里实际调了啥。所以,没报错 ≠ 能运行。

说白了,直接运行 composer check-platform-reqs 只有在项目根目录,且 composer.json 显式写了 PHP 版本或扩展要求时,它才干活。否则它一声不吭,但你的项目 runtime 一跑可能就崩。
必须在项目根目录执行,且依赖 composer.json 显式声明
这个命令有个脾气:它绝不向上查找父目录的 composer.json,也不会去读 vendor/ 或 composer.lock。它只关心当前目录下的那个 composer.json 文件,而且只盯 require 和 config.platform 这两个字段里有没有写平台约束。
- 如果
require里没写"php": ">=8.1"或"ext-zip": "*",那就算项目实际依赖zip扩展,它照样睁一只眼闭一只眼。 config.platform相当于一个“假装环境”的设置——你设成"php": "8.1.0",它就按 8.1.0 去比对,不管你本地真实的php -v输出是多少。- 拼错字段名?比如写成
"platfrom",配置会被静默忽略,检查结果看似正常,实则失效——这是个容易踩的坑。
PHP CLI 和 Web 环境不一致是常见误报根源
check-platform-reqs 总是用 Composer 当前调用的 PHP CLI 二进制来检查,而你在命令行手动敲 php -m 时可能用了另一个版本。这就是为什么它报 ext-zip: * (missing),你查又说确实存在——两个世界,互不通气。
- 先确认 Composer 用的是哪个 PHP:
which php,再用那个完整路径执行:/usr/bin/php -m | grep zip。 - macOS 上 Homebrew 安装的 PHP 经常因为 PATH 顺序导致 CLI 默认调用系统旧版(不带 zip),而
php -v看到的是新版本。 - Windows 用户注意:
composer可能调C:\php\php.exe,而命令行默认是C:\xampp\php\php.exe,两者php.ini和扩展目录完全不同。
它不检查代码实际调用的扩展,只认 composer.json 的 require
这个命令不会扫描你的 PHP 源码,也不会解析已安装包内部的逻辑。打个比方:哪怕某个包在 src/ 里硬调了 openssl_encrypt(),只要它的 composer.json 没在 require 里写 "ext-openssl": "*",check-platform-reqs 就完全不管。
- 它无视
conflict、provide、require-dev(除非加--no-dev参数)里的平台声明。 - 它不验证
php.ini运行时设置,比如memory_limit、opcache.enable、upload_max_filesize——这些得单独用php --ini和php -r 'var_dump(ini_get("memory_limit"))'来查。 - Web SAPI(比如 Apache mod_php / PHP-FPM)和 CLI 用的是不同的
php.ini,所以命令行通过 ≠ 网页能跑。
真正容易被忽略的是:它只告诉你「声明的约束是否满足」,不是「代码能不能跑」。上线前别只信它输出的 OK——composer install --dry-run 和真实环境下的 phpinfo() 页面,才是更贴近实际的验证手段。


































