composer check-platform-reqs 是主动检查本地 cli 环境是否满足 composer.json 中显式声明的 php 版本与扩展依赖的诊断命令，仅比对 require 和 config.platform 字段，不扫描代码实际调用、不校验 web 环境或未声明依赖；配 platform 会使其按“虚拟环境”校验而掩盖真实兼容风险，故开发中应避免使用。
Composer 的平台限制不是用来“绕过”环境问题的，而是主动声明项目运行边界——用错地方会掩盖真实兼容风险，甚至导致线上报错。
platform 配置为什么会让 check-platform-reqs 失效
你在 composer.json 里加了 "platform": {"php": "8.1"}，composer check-platform-reqs 就不再看本地 PHP 是 8.2 还是 8.3，它只校验你“假装”的这个 8.1 环境是否满足依赖要求。
- 这是设计行为，不是 bug：platform 是为 CI 构建、Docker 多阶段编译等“目标环境固定”场景准备的
- 本地开发时配了 platform，
check-platform-reqs就失去验证意义——它不报错，不代表你机器真能跑 -
--no-platform-check参数对check-platform-reqs无效，它只影响install/update时的自动校验环节
怎么确认 check-platform-reqs 真正在检查什么
别猜，直接看 Composer 内部认定的平台能力：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer show --platform，输出就是它校验所依据的数据源（例如php: 8.2.12、ext-zip: 8.2.12） - 如果
composer.json里写了"php": "^8.3"，但show --platform显示php: 8.2.12，那check-platform-reqs必然失败 - 这个命令不读
platform配置，它反映的是真实 CLI 环境探测结果——这才是你该信任的基准
ext-zip 显示 missing 但 php -m 能看到，怎么快速定位
根本不是扩展没装，是 Composer 和你终端用的不是同一个 php 二进制：
- 执行
which php和composer config --global bin-dir，确认 Composer 启动路径 - 用完整路径复现：比如
/opt/homebrew/bin/php -m | grep zip，而不是只敲php -m - macOS 上 Homebrew 安装的 PHP 常被系统自带旧版覆盖；Windows 上注意
C:\php\php.exe和C:\xampp\php\php.exe可能共存 -
platform配置会进一步干扰判断——删掉它再试，才能暴露真实路径差异
为什么 check-platform-reqs 不报 openssl 缺失，install 却失败
它只检查 composer.json 的 require 字段里明确写的扩展，不扫描代码里实际调用的函数：
- 某包在
src/里用了openssl_encrypt()，但它的composer.json没写"ext-openssl": "*"，check-platform-reqs就完全不管 -
conflict或provide字段里的扩展声明，它也无视 - 更靠谱的验证方式是
composer install --dry-run：它会尝试加载 autoloader 并触发部分扩展初始化逻辑，比纯静态检查早一步暴露问题
真正容易被忽略的是：platform 配置一旦写进 composer.json，就会影响所有成员的本地开发体验——它让 check-platform-reqs 变成一个“自我验证”的闭环，而非环境探针。除非你在写 CI 脚本或构建 Docker 镜像，否则它不该出现在日常开发配置里。
