composer check-platform-reqs 是检测当前 cli 环境是否满足 composer.json 中显式声明的 php 版本与扩展要求的最准方式；但它不读代码、不查 web 环境、也不管漏写——通过 ≠ 能跑。
直接运行 composer check-platform-reqs 是检测当前 CLI 环境是否满足 composer.json 中显式声明的 PHP 版本与扩展要求的最准方式；但它不读代码、不查 Web 环境、也不管你漏写了什么——通过 ≠ 能跑。
为什么 composer diagnose 查不出 PHP 版本问题
composer diagnose 只确认 Composer 自身能不能启动：比如 curl 扩展有没有、CA 证书路径对不对、vendor/ 目录可不可写。它完全不打开 composer.json，更不会看里面写的 "php": "^8.2"。
常见误判场景：
-
diagnose全绿，但composer install报Your requirements could not be resolved—— 因为本地是 PHP 8.1，而 require 要求 8.2+ -
php vendor/autoload.php直接 fatal error（比如用了match语法）——diagnose压根不校验运行时语法兼容性 - 报
[FAIL] GitHub API is not working，但实际只是 token 过期或限流，跟 PHP 版本毫无关系
composer check-platform-reqs 真正在比对什么
它只做一件事：把 composer.json 的 require 和 config.platform 字段里明确写出的约束，和当前 CLI 环境的真实能力做比对。
必须注意的细节：
- 只检查
require里写的，比如"php": ">=8.1.0"或"ext-zip": "*"；漏写 = 漏检查 - 扩展名必须带
ext-前缀，写成"zip": "*"会被静默跳过 -
config.platform是“假装环境”，设了"php": "8.1"，它就按这个验，无视你php -v输出的 8.2.12 - 它调用的是
extension_loaded('zip')这类运行时函数，不是查php.ini文件是否存在
为什么它报 ext-zip: * (missing)，但 php -m | grep zip 却有
根本不是扩展没装，而是 Composer 和你敲命令时用的不是同一个 PHP 二进制。
快速定位方法：
- 执行
which php和composer config --global bin-dir，确认 Composer 启动路径 - 用完整路径复现：
/opt/homebrew/bin/php -m | grep zip（macOS Homebrew）、C:\php\php.exe -m | findstr zip（Windows） - 检查该 PHP 对应的
php.ini是否启用了扩展：/opt/homebrew/bin/php -r "var_dump(extension_loaded('zip'));" - 删掉
composer.json里的"platform"段再试，避免模拟层干扰判断
它通过了，项目就真能跑？
不能。它只告诉你「声明的约束被满足了」，不保证：
- 代码里调用了
openssl_encrypt()，但composer.json没写"ext-openssl": "*"—— 完全不报 -
php.ini里memory_limit = 16M导致 autoload 失败 —— 它不读 ini 设置 - Web 环境（PHP-FPM / Apache）没启用同名扩展 —— 它只查 CLI
- 扩展虽加载，但依赖的底层库缺失（如
ext-intl缺 ICU）—— 它不探测依赖库
真正容易被忽略的是：这个命令的输出，永远受限于你 composer.json 写了什么；写得越少，它查得越浅。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
