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 或手动验证。