composer diagnose 显示 ok 仅表示 composer 能安全启动，不校验 php 版本、扩展可用性、私有仓库连通性或 platform 配置真实性，其检查限于 composer.json 合法性、基础扩展加载、ca 证书路径及对 packagist.org 和 github api 的简单连通性。

composer diagnose 显示 OK，不代表你能顺利 install 或 update —— 它只验证 Composer 能不能“安全启动”，不校验你项目里 require 的扩展、PHP 版本、私有仓库连通性或 platform 配置真实性。

composer diagnose 检查什么、不检查什么

它默认执行约 10 项轻量检查，全部基于当前目录下的 composer.json 和本地环境状态：

• composer.json 是否为合法 JSON，且含必需字段（如 name、require）
• vendor/ 目录是否存在、当前用户是否有读写权限
• openssl、curl、zip、json 等 PHP 扩展是否已加载（但不验证是否被 disable_functions 禁用）
• CA 证书路径是否可读（影响 HTTPS 请求）
• 能否对 https://packagist.org 发起 HEAD 请求（硬编码，无视镜像配置）
• 能否访问 https://api.github.com/rate_limit（依赖 GITHUB_TOKEN 或 ~/.composer/auth.json）

它不检查：PHP 版本是否满足 require 中的约束、ext-redis 是否真的可用、platform 配置是否与实际匹配、autoload 映射路径下文件是否存在、私有仓库 DNS 是否可达、memory_limit 是否足够解压 ZIP 包。

为什么 diagnose 显示 OK 却 install 失败

这是最常被误判的点。典型脱节场景包括：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• composer.json 写了 "ext-redis": "*"，但系统没装 redis 扩展 → diagnose 不报错，install 直接中断
• "config": {"platform": {"php": "8.2.0"}}（末尾多了个 .0）→ diagnose 认为合法，update 却报 platform config is invalid
• 用了阿里云镜像但 URL 少了末尾 / → diagnose 显示 Repo is default，实际仍走官方源，下载慢还可能限流
• CI 环境中 ~/.composer/config.json 是 root 创建、当前用户无读权限 → diagnose 跳过全局配置检查，却仍尝试用失效 token 访问 GitHub API

加 -v 和 --strict 有什么实际区别

-v（或 --verbose）让你看见“它到底在查什么”，--strict 则把警告当错误——但二者作用对象完全不同，混用容易误判：

• composer diagnose -v 输出每项检查的细节：比如具体哪个目录权限不足、CA 证书路径在哪、GitHub rate limit 剩多少次、Git 用户名是否为空
• composer diagnose --strict 把原本只是 warning 的问题（如 composer.lock is not up to date）升级成 error，但它不检查 lock 文件内容是否损坏，只看时间戳
• 两者不叠加生效：--strict 不让 -v 显示更多项，-v 也不让 --strict 多检查任何新东西
• CI 脚本里慎用 --strict：它会把“lock 文件不是最新”这种提示当失败，而你可能正准备跑 update，这反而是预期状态

哪些问题必须手动补位

composer diagnose 是轻量级自检，不是环境审计工具。它跳过所有需要真实执行、解析或网络请求的环节。必须人工验证的关键项：

• 用 php -m | grep -E "openssl|zip|mbstring" 确认 CLI 模式下扩展真实启用
• 运行 php --ini 核对 CLI 使用的 php.ini 路径，检查 extension=openssl 是否未被注释、disable_functions 是否禁用了关键函数
• 测试 autoload：手动 require 'vendor/autoload.php' 并调用一个类，看是否报 Class not found
• 验证私有仓库：用 curl -I https://your-private-repo.com/packages.json 或 composer show -p | head -5（后者走当前配置源）
• 检查 CA 证书：运行 curl -I https://packagist.org，如果也报 SSL 错，问题在系统或代理层，不是 Composer 配置问题

真正卡住 install 的，往往藏在 diagnose 的“盲区”里：比如 platform 配置伪造了 PHP 版本，或 repositories 地址 DNS 解析失败但没配 GitHub token 导致诊断跳过网络检查 —— 这些得靠人盯日志、抓包、换环境试。