Composer check-platform-reqs如何运行_Composer兼容性检测说明

你可能会觉得，跑一遍 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() 页面，才是更贴近实际的验证手段。