composer diagnose 默认检查10项基础配置，但不验证镜像源、auth.json凭据及包下载能力；加-v可查看详细失败原因，手动补全SSL、权限、代理等诊断。
composer diagnose 能快速发现本地 Composer 环境的常见配置问题，但默认只检查基础项，很多实际报错（比如 Could not find package、SSL certificate problem、Permission denied）它压根不报——得配合手动验证才能准确定位。
composer diagnose 检查了哪些项目
它默认运行 10 项检查，包括：composer.json 格式合法性、vendor/ 目录是否存在、openssl 扩展是否启用、curl 是否可用、CA 证书路径是否可读、git 命令是否在 $PATH 中、unzip 是否可用、phar 写入权限、detect_unicode 是否关闭、以及是否能访问 https://repo.packagist.org（仅 HEAD 请求）。
注意：composer diagnose 不验证镜像源配置是否生效，也不检查 auth.json 凭据是否正确，更不会尝试下载包——这些都得你手动补。
怎么让 diagnose 更有用
加 -v 或 --verbose 参数能看到每项检查的具体执行逻辑和失败原因；加 --no-ansi 可避免颜色干扰日志采集；若只想检查某几项，目前没有原生开关，只能靠排除法：先全量跑一次，再结合错误提示单独验证对应环节。
- 遇到
SSL certificate problem类错误，手动执行：curl -I https://repo.packagist.org和php -r "print_r(openssl_get_cert_locations());" - 怀疑镜像失效？运行：
composer config repo.packagist.org确认是否为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}这类合法结构 -
Permission denied在vendor/？检查当前用户对vendor/及其父目录的写权限，尤其 Docker 容器内常因 UID 不匹配导致
常见误判和绕过场景
composer diagnose 会把「能连通 Packagist」等同于「网络正常」，但实际可能被 DNS 污染或 HTTP 代理拦截——它用的是 HEAD，而 install 用的是 GET，行为不一致。
另外，它默认跳过对 auth.json 的校验。如果你用私有包，即使 diagnose 显示全部 OK，仍可能在 require 时卡在 Authentication required。
- 私有 Git 仓库认证问题？手动跑：
git ls-remote -h https://github.com/xxx/yyy.git - HTTP 代理导致超时？临时禁用：
export HTTP_PROXY=; export HTTPS_PROXY=; composer diagnose - Windows 下
cafile路径含空格？composer config --global cafile "C:/Program Files/PHP/cacert.pem"必须用正斜杠且不加引号
真正卡住你的往往不是 composer diagnose 报出的问题，而是它没报、但实际影响命令执行的环境细节——比如 PHP 的 open_basedir 限制、SELinux 上下文、或者 WSL2 中 Windows 主机防火墙拦截了端口转发。
