composer check-platform-reqs 仅报告当前 CLI 环境是否满足 composer.json 中显式声明的 PHP 版本与扩展要求，不安装、不修复、不扫描代码；报 missing 但 php -m 可见，多因 Composer 与终端调用不同 PHP 二进制；加 --lock 则校验 composer.lock 中所有包实际依赖的平台能力，暴露隐性扩展需求；config.platform 会覆盖真实环境用于模拟，开发中应禁用以防掩盖风险。
composer check-platform-reqs 不是补丁命令，也不修复任何问题——它只报告当前 CLI 环境是否满足 composer.json 中**显式声明**的 PHP 版本、扩展（如 ext-zip）、库（如 lib-curl）要求。运行它不会安装扩展、不会升级 PHP、也不会修改配置。
为什么它总报 missing，但 php -m 能看到扩展？
这不是扩展没装，是 Composer 和你终端执行 php -m 用的根本不是同一个 PHP 二进制文件。
- 先确认 Composer 实际调用哪个 PHP：
which php，再用该路径查扩展：/opt/homebrew/bin/php -m | grep zip（macOS Homebrew 常见路径）或C:\php\php.exe -m | findstr zip（Windows） - Linux 下 apt 安装的 PHP 和源码编译的 PHP，
.so文件路径和php.ini加载位置可能完全不同 -
php -v显示 8.2，但composer check-platform-reqs用的是/usr/bin/php（系统自带 8.0），就会报php >=8.1 required, you have 8.0.30
加了 --lock 为什么突然报一堆 ext-gmp missing？
composer check-platform-reqs --lock 不再只看 composer.json 里你写的约束，而是直接读 composer.lock，反推所有已安装包**实际依赖的平台能力**。
- 某包 v2.4.0 不依赖
ext-gmp，但 v2.5.0 加了硬依赖 → 不加--lock不会暴露，加了就立刻报错 - CI/CD 部署前必须加
--lock，否则上线后第一次调用gmp_init()就 fatal error -
--lock模式是纯静态比对，毫秒级完成；而composer install --dry-run会模拟解析+网络请求，更慢且不等价
config.platform 怎么让检查结果失效？
"platform": {"php": "8.1.0"} 是“假装环境”，不是“校验环境”——它会让 check-platform-reqs 完全忽略你本地 php -v 输出的 8.2.12，强行按 8.1.0 校验。
- CI 构建时有用：确保不会误装仅支持 PHP 8.2 的包
- 本地开发时禁用：删掉
config.platform段再跑，才能暴露真实兼容风险 - 字段名拼错（如
"platfrom"）、漏写ext-前缀（如"mbstring": "*"）、写成"8.1"（被当精确版本）都会导致静默跳过，不报错也不提醒
vendor/ 包内部逻辑，也不管 php.ini 里 disable_functions 或 opcache.enable 是开是关。 
