Composer diagnose 仅检查PHP版本与扩展、vendor目录权限、composer.json及composer.lock格式合法性，不检测依赖冲突、扩展启用状态、网络连通性或platform配置真实性；通过不代表install成功。
Composer diagnose 命令本身不“一键修复”，它只做两件事：检查当前环境是否满足 Composer 运行基本条件，并验证 composer.json 和 composer.lock 的结构合法性。它不会检测依赖冲突、版本兼容性或自定义脚本错误。
执行 diagnose 时实际检查哪些项目
运行 composer diagnose 会依次验证以下几类问题：
- PHP 版本是否在 Composer 支持范围内（例如 v2.x 要求 PHP >= 7.2.5）
- 是否启用了必需的 PHP 扩展，如
json、phar、filter、hash、openssl、zlib（缺任意一个都会报The "xxx" extension is missing） - 当前用户对
vendor/目录是否有写权限（尤其在 CI 环境或 Docker 中容易因 UID 不匹配失败） -
composer.json是否为合法 JSON，且根级字段符合 Schema（比如不能有拼错的"require-devs"） - 若存在
composer.lock，是否能被正确解析（常见于手动编辑 lock 文件后格式损坏）
为什么 diagnose 显示 OK 却仍 install 失败
这是最常被误解的点：composer diagnose 通过 ≠ 项目可正常安装。典型脱节场景包括：
-
composer.json中声明了"ext-redis": "*"，但系统未装 redis 扩展 ——diagnose不检查扩展是否已启用，只检查 PHP 自身扩展是否加载 - 配置了私有仓库（
repositories），但网络不通或认证失效 ——diagnose不发起任何 HTTP 请求 - 使用了
platform配置伪造 PHP 或扩展版本，而真实环境不匹配 ——diagnose不校验 platform 声明与实际是否一致 -
autoload规则语法正确，但 PSR-4 映射路径下实际无对应文件 ——diagnose不扫描文件系统
如何让 diagnose 输出更实用的信息
默认输出较简略，加参数可增强诊断粒度：
- 用
composer diagnose -v查看每项检查的详细判断逻辑（比如具体哪个目录权限不足） - 用
composer diagnose --no-interaction避免在 CI 中卡住（虽然 diagnose 本身不交互，但某些插件可能触发） - 想跳过某项检查？不行 —— 没有
--skip-xxx参数。需要临时绕过只能改源码或 mock 环境（不推荐） - 注意：
composer diagnose不读取COMPOSER_HOME下的全局配置，只检查当前项目上下文
composer diagnose -v Checking composer.json: OK Checking platform settings: OK Checking git settings: OK Checking http connectivity to packagist: OK Checking https connectivity to packagist: OK Checking github.com rate limit: OK Checking disk free space: OK Checking pubkeys: Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0 87719BA6 8F3BB723 4E5D42D0 84A14642 Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B 0C708369 153E328C AD90147D AFE50952 OK Checking composer version: You are not running the latest stable version, run `composer self-update` to update
真正关键的不是 diagnose 是否通过，而是它没检查到的地方 —— 比如平台扩展真实性、仓库可用性、网络策略、以及 lock 文件与 json 的语义一致性。这些得靠 composer install --dry-run 或手动验证。
